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EXECUTIVE  SUMMARY 


This  report  responds  to  USD  (AT&L)’s  (Under  Secretary  of  Defense  (Acquisition, 
Technology  and  Logistics)  25  June  2001  tasking  to  the  Single  Integrated  Air  Picture 
(SIAP)  Acquisition  Executive.  The  memorandum  requested  a  report  on  the  Single 
Integrated  Air  Picture  System  Engineering  Task  Force’s: 

o  Progress, 

o  Plans  to  define  the  SIAP  Integrated  Architecture,  identify  and  resolve 
problems  with  the  Joint  Data  Network  (JDN),  and  define  the  elements  of 
the  Joint  Composite  Tracking  Network  (JCTN)  and 
o  Emerging  issues  and  recommendations 

A  key  driver  behind  this  request  stemmed  from  OASD  (C3I)  and  OUSD  (AT&L) 
questions  regarding  how  the  DoD  would  develop  a  JDN/JCTN  roadmap.  Our  approach 
is  to  use  DoD’s  C4ISR  architectural  discipline  to  flow  requirements  to  materiel 
alternatives  that  will  define  that  roadmap.  We  began  by  assuming  the  proposed  JCTN 
concept  represented  an  accurate,  low  latency  network  (Integrated  Fire  Control  (IFC) 
being  one  of  the  key  engineering  drivers).  We  expect  to  have  our  initial  draft  of  the 
SIAP  architectural  framework  by  December  2002. 

This  report  captures  key  events,  ideas  and  operational  factors  that  drove  DoD 
decisions  to  establish  the  SIAP  System  Engineering  Task  Force.  It  outlines  the 
architectural  process  the  Task  Force  expects  to  follow  in  building  the  architectural 
framework  for  the  SIAP  component  of  the  Theater  Air  and  Missile  Defense  (TAMD) 
Integrated  Architecture  —  the  roadmap  is  a  piece  of  this  architecture. 

JROC-validated  Capstone  Requirements  Documents  (CRDs)  define  Joint 
warfighter  objectives  and  identify  key  performance  parameters  (KPPs)  for  Joint 
operations.  The  recently  af^roved  Theater  Air  and  Missile  Defense  (TAMD),  Combat 
Identification  (Cl D),  Information  Dissemination  Management  (IDM)  and  Global 
Information  Grid  (GIG)  CRDs  provide  the  overarching  requirements  for  the  SIAP.  To 
put  these  CRDs  in  context,  the  Task  Force  launched  several  engineering  initiatives  that 
define  the  operational  context  and  provide  measures  of  progress  toward  the  CRDs 
objective  SIAP.  But,  to  engineer  tomorrow  we  must  understand  the  forces  of  today. 

Many  systems  contribute  to  the  air  picture.  Understanding  the  differences 
between  our  current  capabilities  and  those  required  for  future  operations  identify  the 
gap  that  DoD  must  bridge.  We  have  started  down  this  path  by  looking  at  our  current 
capabilities  and  known  deficiencies.  We  have  also  begun  defining  some  operational 
scenarios  in  which  our  Joint  forces  will  be  expected  to  operate  in  the  future.  These 
scenarios  can  then  be  "gamed"  through  modeling  and  simulation  to  determine  the 
capabilities  that  will  be  required  in  the  future  as  approved  by  the  JROC.  This  analytical 
framework  should  then  help  DoD  with  insight  into  the  linkage  between  engineering 
alternatives  and  their  impact  on  military  utility.  The  decisions  that  result  from  this 
analysis  will  be  captured  in  SIAP  architectural  documents.  This  architectural  repository 
will  provide  not  only  a  means  to  measure  improvements  from  the  current  baseline,  but 


i 


also  provides  an  audit  trail  for  the  functional  allocations  required  to  meet  Joint 
warfighting  requirements. 

The  task  challenging  the  SIAP  System  Engineer  is  complex,  and  architecture  is 
central  to  an  orderly  and  methodical  approach  to  achieving  the  SIAP.  Legislation  in  the 
form  of  the  1 996  Clinger-Cohen  Act  directed  DoD  to  develop  and  maintain  information 
technology  architectures.  Through  the  Secretary  of  Defense,  the  Department 
established  the  C4ISR  Framework  as  the  template.  Other  DoD  regulations  and 
instructions  have  been  issued  that  help  define  the  documents  required  to  record  the 
engineering  of  these  complex  problems. 

While  the  terms  Joint  Planning  Network  (JPN),  Joint  Data  Network  (JDN),  and 
Joint  Composite  Tracking  Network  (JCTN)  are  used  frequently,  there  is  no  widely 
accepted  definition  for  any  of  these  networks.  Rather  than  debate  the  definitions,  the 
Task  Force  began  an  architectural  development  effort  that  will  define  the  required 
functionality.  We  also  expect  the  architecture  to  support  analysis  of  functional  gaps, 
overlaps,  duplicative  efforts  and  conflicts.  This  analytical  approach  to  an  integrated 
architecture  will  translate  requirements  and  define/allocate  functionality  to  weapon 
systems  that  can  be  mapped  back  to  these  network  concepts. 

This  SIAP  Integrated  Architecture  (lA)  will  define  the  Joint  interfaces,  functional 
and  allocated  baselines,  associated  information  exchange  requirements  (lERs)  and 
data  models.  These  models  serve  as  the  basis  for  SIAP  implementation  trade  studies 
and  requirements  allocation.  The  architecture  will  support  developers  and  testers;  and 
is  a  tool  for  enforcing  integrated  implementation  of  SIAP  functional  requirements. 
Architecture  products,  such  as  the  System  Capability  Evolution  Description  will  outline 
this  integrated  implementation  that,  with  JROC  endorsement,  will  provide  the  roadmap 
toward  an  objective  SIAP. 

The  Task  Force  initially  focused  on  the  description  of  physical  systems  and  their 
interfaces.  The  plan  was  to  start  with  a  small  list  of  systems/functions  and  then  add 
additional  systems  and  functions  in  an  incremental  fashion.  The  functional  descriptions 
were  focused  on  the  breadth  of  the  SIAP  capability  first,  and  then  followed  with 
additional  detail  in  specific  functional  areas.  As  the  functional  analysis  matures,  the 
data  and  information  exchanges  will  be  refined  and  a  behavior  analysis  will  be 
conducted. 

To  evaluate  the  existing  air  picture,  the  Task  Force  developed  a  set  of  SIAP 
attributes,  measures  of  effectiveness  (MOEs)  and  measures  of  performance  (MOPs) 
that  would  be  quantifiable,  testable  and  measurable.  These  SIAP  attributes  established 
a  set  of  metrics  that  is  derived  from  KPPs  defined  in  the  previously  mentioned  CRDs.  In 
developing  these  metrics  we  encountered,  and  are  endeavoring  to  resolve,  metrics 
implementation  issues  that  surfaced  when  we  attempted  evaluate  data  from  live  tests  or 
simulations.  By  providing  guidance  on  how  to  use  these  metrics  we  plan  to  further 
standardize  community  practices  to  ensure  these  metrics  retain  the  proper  engineering 
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context.  These  analytical  tools  will  be  our  keys  to  baselining  current  performance  and 
determining  the  value  of  incremental  SIAP  improvements 

However,  in  evaluating  these  incremental  improvements,  these  engineering  tools 
will  not  be  sufficient  to  evaluate  tradeoffs  unless  we  reach  agreement  on  a  standardized 
set  of  warfighting  scenarios.  These  Common  Reference  Scenarios  (CRSs)  are  being 
built  in  cooperation  with  JTAMDO  and  JFCOM,  and  will  provide  a  standardized 
modeling  framework  in  which  to  test  proposed  changes  to  the  equipment  and  TTP 
which  effect  the  SIAP.  These  scenarios  are  based  on  approved  regional  war  plans  and 
include  details  such  as  friendly  and  enemy  force  laydowns,  terrain,  and  timelines  for 
modeling  the  impact  of  SIAP  system  modifications.  By  evaluating  system  responses  in 
a  common  context  the  Task  Force  can  analytically  tie  engineering  changes  to  potential 
warfighter  effectiveness  improvements. 

To  augment  this  modeling  and  simulation  capability  we  plan  to  use  hardware-in- 
the-loop,  operator-in-the-loop,  and  live  exercises  to  support  our  work.  By  gathering  and 
comparing  results  from  these  different  venues,  we  expect  to  validate  the  models  and 
testbeds.  The  validation  process  will  build  confidence  in  these  tools  and  help  us  toward 
our  goal  of  providing  empirical  data  to  support  engineering  decisions. 

We  selected  Block  0  as  a  pilot  to  help  us  mature  our  tool  set  and  frame  up  an 
analytical  process  for  making  these  collaborative  engineering  decisions.  Our  Block  0 
effort  built  relationships,  refined  communication  paths  and  identified  administrative, 
programmatic,  financial  and  technical  lessons  learned.  As  a  result,  in  September  2001 
the  JROC  directed  Block  0  implementation  and  recommended  Services  plan  for 
continued  Joint  engineering  through  FY03.  These  additional  funds  will  allow  the  Task 
Force  to  start  and  complete  Block  1  Joint  engineering. 

Block  1  engineering  will  build  on  our  Block  0  experience  in  helping  DoD  refine  the 
SIAP  System  Engineering  process.  This  incremental  approach  will  help  us  introduce 
weapon  system  changes  in  an  orderly,  fiscally  achievable  manner,  while  retaining 
engineering  flexibility  as  we  flesh  out  a  SIAP  Integrated  Architecture.  Between  these 
two  efforts  we  will  build  the  objective  SIAP  capability.  The  Block  upgrade  process  will 
define  work  that  needs  to  be  done  while  the  architecture  is  being  developed  and  the 
architecture  will  provide  the  top  down  descriptions  of  how  systems  should  work  together 
to  meet  JROC-validated  requirements. 

This  SIAP  lA  will  be  derived  from  the  JTAMD  2010  Operational  Architecture 
(validated  by  the  JROC  in  November  2001).  We  anticipate  initial  product  delivery  from 
the  SIAP  architecture  in  February  2002  and  our  first  draft  of  the  "objective"  SIAP  lA  in 
December  2002. 

The  SIAP  lA  serves  several  key  functions  by  defining  relationships  through  a 
series  of  structured  views— the  Operational,  System  and  Technical  Views. 
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Warfighters  communicate  with  engineers  through  the  Operational  Views.  In 
these  views  the  architecture  shows,  in  graphical  and  tabular  form,  how  we  intend  to  fight 
by: 

-  Describing  interrelationships  among  warfighting  units, 

-  Describing  the  functions  that  warfighting  units  will  perform  individually  and 
collectively,  and, 

-  Defining  how  well  those  functions  must  be  performed  to  satisfactorily 
accomplish  the  assigned  mission  in  the  most  effective  way. 

By  decomposing  these  operational  relationships  the  architect  will  uncover  other 
critical  system  and  technical  relationships,  functions  and  definitions.  This  work  will 
create  a  shared  repository  of  system  engineering  artifacts  that  will  document  the  results 
of  the  system  engineering  process.  By  capturing  this  design  we  form  a  contract  between 
the  warfighter  and  acquisition  communities:  and,  we  add  fidelity  to  our  communications 
with  industry  through  a  series  of  system  and  technical  views. 

The  System  Views  in  the  SIAP  lA  will  baseline  our  current  interoperability 
performance  and  determine  what  functionality/engineering  changes  need  to  be 
incorporated  or  developed.  To  ease  into  the  complexity  of  these  system  views  we’ve 
used  an  incremental  block  approach  to  isolate  systems/functions  in  fleshing  out  the 
architecture— the  stepping-stones  to  increased  Joint  warfighting  capability. 

Block  0  implementation  will  reduce  dual  tracks  and  decrease  operator  confusion. 
The  key  identification  and  track  correlation  issues  that  made  up  this  initial  block  laid  the 
foundation  for  Block  1  engineering  options. 

Block  1  will  improve  accuracy  and  commonality  and  enhance  combat 
identification  capabilities  while  laying  the  foundation  for  Block  2.  We’ve  focused  on  four 
operational  themes: 

o  Further  reduce  dual  tracks  through  improved  sensor  and  data  registration 
(time,  position,  alignment  and  track  management  issues). 

o  Improve  identification  continuity  and  accuracy  through  improved  integration  of 
current  ID  techniques  and  provide  for  growth  of  emerging  Mode  5  and  Mode 
S  IFF  functions. 

o  Improve  theater  ballistic  missile  defense  (TBMD)  performance  through 
increased  accuracy  in  target/debris  reporting  and  correlation  rules. 

o  Improve  data  sharing  options  such  as  increased  Link  16  throughput,  multi-link 
translation  and  forwarding  and  options  for  engage  on  remote  capability  (ability 
of  a  shooter  to  engage  a  target  tracked  on  another  system’s  fire  control 
radar— this  capability  will  provide  the  basis  for  integrated  fire  control) 
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At  this  stage  in  our  work  we  expect  Block  2  to  build  on  Block  1  by  focusing  on 
improved  Link  16  efficiency  and  throughput,  improved  gateways  with  other  networks 
and  expanded  battle  space  with  improved  beyond  line  of  sight  options. 

In  designing  the  engineering  solutions  for  Block  1  and  posturing  for  subsequent 
blocks,  the  SIAP  SE  will  allocate  functions  and  tolerances  within  the  architectural 
framework.  These  solutions  will  be  measured  against  TAMD  and  CID  requirements  and 
will  lay  the  basis  for  addressing  functionality  among  networks  and  other  platforms.  We 
expect  to  recommend  Block  1  solutions  in  December  2002  along  with  an  initial  draft  of 
the  SIAP  component  of  the  TAMD  Integrated  Architecture. 

As  DoD  considers  concepts  such  as  a  Joint  Composite  Tracking  Network 
(JCTN),  the  architectural  foundation  laid  in  with  Block  1  will  help  focus  issues  on  the 
requirements  for  fleshing  out  these  ideas.  For  JCTN,  the  engineering  accuracy  and 
communication  stressors  anticipated  with  Integrated  Fire  Control  will  likely  drive  the 
functional  allocation  and  define  the  elements  of  the  JCTN  concept. 

To  achieve  these  goals  we  must  stabilize  the  resources  needed  to  do  this  work. 
This  will  require  the  Services  to  work  with  DoD  to  plan  and  program  for  this  activity. 
Budgets  must  support  three  distinct  funding  categories: 

o  Joint  Engineering — Tier  1 — ^this  funding  supports  the  collaborative 

engineering  process.  During  FYOO-03  the  SIAP  SE  Task  Force  consolidated 
these  funds  in  a  single  Navy  program  element  for  conducting  the  engineering 
analyses  underpinning  the  incremental  block  development  process  and 
architectural  design  work. 

o  Service  Engineering — ^Tier  2 — these  funds  remain  with  each  Service  and 
should  be  designated  to  resolve  the  Service  specific  SIAP  related  issues. 
These  funds  also  provide  the  foundation  for  Service  validation  of  engineering 
models  and  personnel  costs  for  supporting  the  Joint  engineering  effort. 

o  Service  Implementation  costs— Tier  3 — ^these  Service  funds  should  be 

programmed  within  Service  system  program  elements  to  provide  for  periodic 
system  updates  of  applicable  Service  legacy  and  developmental  systems. 

By  providing  resource  lines  in  the  Service  budgets  DoD  will  create  the  focus 
needed  to  stabilize  the  Service  manpower  and  industrial/Service  support  needed  to  turn 
engineering  designs  into  improved  Joint  warfighting.  The  FY01  funding  allocation 
progress  has  been  slow  and,  as  a  result,  limited  the  depth  and  aggressiveness  in 
building  the  Task  Force’s  engineering  foundation. 

It  took  nearly  a  year  to  staff  the  Task  Force  and  in  June  2001  we  hit  the  directed 
end-strength.  Although  we  still  have  challenges  in  maintaining  some  Service  quotas, 
we  must  manage  the  attrition  and  reduce  rotation  to  promote  stability  in  the  workforce. 
Services  typically  lack  depth  in  the  engineering  manpower  to  do  this  Joint  engineering 
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and  the  incremental  resource  strategy  to  date  has  not  provided  the  confidence  needed 
to  recruit  engineers  to  engage  in  long  term  Joint  engineering.  The  Services  should  lay 
in  out-year  programs  and  create  budget  options  that  will  promote  stability  and  move 
interoperability  above  the  cut  line. 

As  the  Task  Force  establishes  the  engineering  foundation  for  others  to  build  on, 
other  critical  elements  need  to  accompany  this  Joint  engineering  initiative: 

o  JTAMDO  must  complete  the  Operational  Views  of  the  SIAP  Integrated 
Architecture 

o  DOT&E  should  institutionalize  the  SIAP  metrics  as  the  assessment  measures 
for  characterizing  SIAP  performance  and  to  endorse  the  end-to-end  analysis 
process 

o  And  ultimately  USD  (AT&L)  should  assign  an  activity  to  budget  for,  update, 
and  manage  the  configuration  of  the  SIAP  component  of  the  TAMD  Integrated 
Architecture. 

This  SIAP  Integrated  Architecture  should  be  the  basis  for  how  DoD  must  develop 
its  JDN/JCTN  roadmap.  The  Task  Force  made  progress  in  building  initial  segments 
supporting  this  architecture  and  we’ve  mapped  out  the  architectural  discipline  needed  to 
trace  requirements  to  materiel  alternatives  that  will  define  that  roadmap.  It  is  this 
disciplined  approach  that  will  help  DoD  clarify  requirements,  identify  deficiencies  in  the 
JDN  and  define  the  elements  of  the  JCTN  concept.  And,  by  assuming  integrated  fire 
control  will  provide  a  key  engineering  driver  for  future  capability,  we  expect  the  plan 
we’ve  laid  out  in  this  report  will  provide  a  highly  accurate  DoD  network  linking  CRD 
requirements  to  specific  materiel  alternatives. 

We  have  mentioned  a  few  of  the  areas  where  we  need  help.  This  technical 
report  has  drawn  other  conclusions  and  recommendations  on  a  number  of  varying 
levels.  We  have  organized  the  report  to  address: 

Background 

Progress  and  General  Plans 

Specific  Plans 

SIAP  Integrated  Architecture 

Identify  and  Resolve  Problems  with  the  JDN 

Define  the  Elements  of  the  JCTN 

Summary  and  Conclusions 


VI 


We  discuss  objectives,  products  and  milestones,  responsibilities,  approach  and 
resources.  Each  section  expands  on  the  progress  and  plans  of  the  efforts  described  in 
this  summary  and  their  relation  to  the  tasking  directed  by  USD(AT&L).  While  we  offer  a 
number  of  recommendations,  we  don't  yet  have  the  detail  required  to  execute  or 
suggest  what  organization  should  pursue  implementing  these  changes.  As  the  SIAP 
SE  Task  Force  products  mature,  we  will  forward  these  complete  recommendations  to 
the  appropriate  authority. 
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1.  BACKGROUND 


In  this  section,  we  briefly  outline  the  events  and  efforts  that  most  directly 
contributed  to  the  establishment  of  the  SIAP  SE  Task  Force.  It  is  necessary  to 
understand  these  actions  and  activities,  as  they  provide  the  context  within  which 
decisions  to  establish  this  group  have  been  made.  Additionally,  this  outline  provides 
some  insight  into  the  scope  of  the  effort  that  will  be  described  in  later  sections. 

Understanding  that  significant  warfighting  capability  shortfalls  exist,  the 
Department  of  Defense  has  given  high  priority  to  improving  the  capability  of  U.S.  forces 
to  operate  together,  as  well  as  with  allied  and  coalition  forces.  Toward  that  end,  a  broad 
range  of  organizations  and  programs  have  been  instituted  by  DoD  components, 
including  the  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics 
(USD(AT&L)),  the  Assistant  Secretary  of  Defense  for  Command,  Control, 
Communications,  and  Intelligence  (ASD(C3I)),  the  Department  of  Defense  Chief 
Information  Officer  (DoD  CIO),  the  Joint  Staff,  Joint  Forces  Command  (JFCOM),  the 
Missile  Defense  Agency  (MDA),  the  Joint  Theater  Air  and  Missile  Defense  Organization 
(JTAMDO),  the  Services,  and  other  defense  agencies  and  organizations. 

In  1994,  the  Defense  Science  Board  (DSB)  concluded  in  its  Summer  Study  on 
Cruise  Missile  Defense  that  "motivation  exists  for  regional  adversaries  to  acquire  land 
attack  cruise  missiles"  and  that  "readily  available  and  emerging  technologies  make  it 
possible  that  a  threat  from  such  systems  could  rapidly  emerge."  The  evolving  threat  of 
modern  aircraft,  tactical  ballistic  missiles  and  now  cruise  missiles  presented  a  challenge 
too  tough  for  any  one  service  to  counter  effectively  on  its  own,  especially  given  the  post- 
Cold  War  reduced  force  structure.  The  growing  proliferation  of  weapons  of  mass 
destruction  added  to  the  sense  of  urgency.  The  DSB  recommended  that  cruise  missile 
defense  measures  be  pursued  within  the  context  of  overall  theater  air  defense  and 
found  that  "integration  of  the  separate  service  activities  into  an  effective  joint  theater  air 
defense  will  require  the  Department  of  Defense  to  establish  joint  requirements/doctrine 
in  an  organization  closely  coupled  to  a  system  engineering/acquisition  organization." 

The  ensemble  of  systems  that  provide  the  capabilities  to  perform  air  and  missile 
defense  functions  in  theater  is  often  called  the  Integrated  Air  Defense  System  (IADS). 
The  Integrated  Air  Defense  System  is  comprised  of  humans,  equipment,  and  computer 
programs.  The  existing  IADS  is  a  de  facto  architecture,  albeit  poorly  documented.  The 
lack  of  an  orderly,  disciplined  approach  to  engineering  and  fielding  the  IADS  has 
resulted  in  functional  gaps,  overlaps,  conflicts,  and  interface  standards  and 
specifications  that  define  not  only  the  interface,  but  functionality  on  either  or  both  sides 
of  the  interface.  The  IADS  is  supported  by  multiple  tactical  data  link  (TDL)  networks, 
which  are  often  characterized  as  the  Joint  Data  Network  (JDN).  Shortfalls  within  the 
JDN  generally  result  in  limitations  in  the  capability  to  reduce  the  potential  of  fratricide,  to 
operate  weapon  systems  to  their  full  design  capabilities,  and  to  improve  warfighting 
capability  against  emerging  threats. 
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The  Joint  Integrated  Air  Defense  System  Interoperability  Working  Group  (JIADS 
IWG)  formed  during  the  All  Service  Combat  Identification  Evaluation  Team  (ASCIET)  96 
evaluation  in  response  to  frustration  caused  by  long-standing  interoperability  problems 
highlighted  during  that  evaluation.  This  ad  hoc  group,  comprised  of  operators  and 
engineers  from  the  services  plus  selected  DoD  Agencies,  adopted  a  proven,  disciplined 
system  engineering  process  to  characterize  and  address  outstanding  “interoperability” 
issues.  The  JIADS  IWG,  working  across  service  and  program  lines,  identified  and 
resolved  “interoperability”  issues,  using  ASCIET  evaluations  as  their  data  collection 
forums.  Because  the  JIADS  IWG  was  ad  hoc,  it  drew  resources  from  Service 
acquisition  programs  that  had  systems  in  the  ASCIET  evaluations,  as  well  as  from 
JTAMDO  and  MDA. 

A  joint  working  group  composed  of  representatives  from  the  Office  of  the 
Secretary  of  Defense,  Joint  Staff,  and  the  Services  convened  in  1996  to  develop  the 
concept  for  the  Joint  Theater  Air  and  Missile  Defense  Organization  (JTAMDO).  On  2 
March,  1997,  JTAMDO  was  established  to  coordinate  with  the  warfighting  CINCs  and 
Services  to  develop  the  joint  operational  concepts,  capstone  requirements,  and 
operational  architecture  for  fielding  a  joint,  integrated  theater  air  and  missile  defense 
(TAMD)  capability.  The  joint  working  group  also  developed  the  joint  theater  air  and 
missile  defense  (JTAMD)  process,  designed  to  integrate  the  requirements  activities  with 
the  acquisition  activities  of  the  services  and  the  Ballistic  Missile  Defense  Organization. 
DoD  had  the  organizational  structure  and  process  in  place  to  begin  to  achieve  the  joint 
TAMD  operational  capabilities  it  needed  for  the  future. 

The  Deputy  Director,  Ballistic  Missile  Defense  Organization  and  CINCUSACOM 
developed  the  concept  of  the  TAMD  Flag  Officer/General  Officer  (FOGO)  Workshop  in 
1998.  The  initial  workshop  was  held  in  August  1998  and  annually  thereafter  for  three 
years.  CINCUSJFCOM,  Director,  MDA,  and  Director,  JTAMDO  sponsored  the 
Workshops.  The  purpose  of  the  workshops  was  to  bring  together  senior  leadership 
from  the  TAMD  operational  and  acquisition  communities  to  address  issues  designed  to 
enhance  current  and  future  Joint  TAMD  operations. 

The  first  workshop  (FOGO  I)  was  held  in  August  1998  at  the  Joint  National  Test 
Facility  (JNTF).  During  that  session,  the  FOGO  established  that: 

•  The  Theater  Missile  Defense  (TMD)  Capstone  Requirements  Document 
(CRD)  was  the  approved  statement  of  joint  warfighting  requirements  for  TMD. 

•  Only  the  interoperable  family  of  TAMD  systems  required  by  the  TMD  CRD 
would  satisfy  geographical  Commanders’  in  Chief  (CINCs’)  requirements. 

•  Continuous  leadership  attention  to  the  engineering  and  acquisition  process 
was  necessary  to  achieve  the  required  level  of  interoperability  in  a  reasonable 
amount  of  time. 

The  second  workshop  (FOGO  II)  was  held  on  31  August  and  1  September  1 999 
at  Tactical  Training  Group  Atlantic.  During  that  session,  the  FOGO  established  that: 

•  The  CINCs  and  Services  supported  by  JTAMDO  would  further  refine  and 
reach  consensus  on  an  operational  concept  for  JTAMD. 
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•  A  balanced  Doctrine,  Organization,  Training,  Materiel,  Leadership,  and 
Personnel  (DOTMLP)  approach  to  TAMD  that  was  properly  synchronized  with 
the  systems  acquisition  process  was  required. 

•  Interoperability  was  a  key  TAMD  enabler,  yet  assessing  and  reporting 
interoperability  among  joint  forces  continued  to  be  a  major  challenge. 

•  Chairman,  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  31 70.01  A  was  a  timely  and 
credible  effort  by  the  Joint  Staff  (JS)  J8  to  focus  future  interoperability  efforts. 

The  third  workshop  (FOGO  III)  was  held  on  2  and  3  August  2000  at  Naval 
Amphibious  Base  (NAB)  Little  Creek  in  Norfolk,  Virginia.  During  that  session,  the 
FOGO  addressed  the  progress  made  since  FOGO  II  and  discussed  those  areas  where 
further  focus  was  required.  They  reviewed  the  current  status  of  the  TAMD  Operational 
Concept  and  TAMD  CRD  and  issues  related  to  major  TAMD  initiatives  to  include  the 
TAMD  Family  of  Systems  (FoS)  and  the  recently  established  Single  Integrated  Air 
Picture  (SIAP)  System  Engineer  (SE). 

The  TAMD  FOGO  workshop  participants  agreed  to  the  following: 

•  Endorsement  of  all  four  elements  of  the  TAMD  Operational  Concept  (Single 
Integrated  Air  Picture  (SIAP);  Combat  Identification  (CID);  Integrated  Fire 
Control  (IFC)  and  Automated  Battle  Management  Aids  (ABMA)).  SIAP  and 
CID  are  the  foundation  of  this  concept. 

•  Support  for  the  basic  tenets  of  the  draft  TAMD  Capstone  Requirements 
Document  (CRD),  including  the  Key  Performance  Parameters  (KPPs). 

•  Endorsement  of  the  SIAP  System  Engineer  (SIAP  SE),  Joint  Distributed 
Engineering  Plant  (JDEP),  and  MDA  Corporate  Test  and  Evaluation  (T&E) 
efforts.  We  are  counting  on  an  effective  SIAP  System  Engineer. 

•  That  there  is  a  growing  interdependence  of  the  National  Missile  Defense  and 
Theater  Ballistic  Missile  Defense  mission  areas.  This  potential  convergence 
needs  to  be  explored  to  determine  where  related  concepts  and  requirements 
intersect. 

Based  on  these  points  of  agreement,  four  key  JTAMD  actions  were  identified: 

•  USJFCOM,  JTAMDO,  and  the  SIAP  SE  would  focus  on  improving  and 
standardizing  Link  16  implementation.  Included  within  this  activity  would  be  an 
initiative  to  address  the  issue  of  enforcing  standard  symbology  for  TAMD 
systems.  Further,  to  demonstrate  the  effectiveness  of  the  SIAP  SE  Task 
Force,  the  SIAP  SE  would  select  one  USJFCOM  endorsed  warfighting 
capability  shortfall  and  pursue  resolution/approval  through  the  JTAMD  process 
including  endorsement  by  the  JROC. 

•  USJFCOM,  JTAMDO,  MDA,  and  the  Services  would  develop  a  Plan  of  Action 
and  Milestones  (POA&M)  to  implement  the  TAMD  Operational  Concept.  This 
plan  would  address  all  aspects  of  DOTMLP. 

•  USJFCOM  would  continue  to  staff  the  TAMD  CRD  for  JROC  validation  in  Dec 
2000.  JTAMDO  would  continue  analytical  efforts  to  refine  the  CRD  KPP  “to  be 
resolved”  (TBR)  values  through  a  specific  warfighting  benefit  analysis  process. 
The  services  would  assist  in  this  effort. 
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•  USJFCOM  would  identify  joint  TAMD  tactical  level  terminology  definitions  and 
would  coordinate  with  the  Joint  Staff  to  ensure  compliance  within  the  Services. 

Directed  by  the  Joint  Staff,  the  JIADS  IWG  conducted  a  data  collection  and  on¬ 
site  analysis  effort  during  ASCIET  97,  ASCIET  99,  and  ASCIET  2000  to  rapidly  answer 
warfighter  questions  and  to  focus  the  detailed  post-ASCIET  data  analysis  in  support  of 
building  a  Single  Integrated  Air  Picture  (SIAP).  Following  each  of  the  evaluations,  the 
JIADS  IWG  met  to  conduct  in-depth  reconstruction  and  data  analysis.  Results  were 
summarized  in  data  analysis  reports,  which  were  used  to  Justify  changes  to  interface 
standards  (e.g.,  MIL-STD-6016A)  and  host  system  implementations  of  those  standards. 

While  ASCIET  2000  was  being  planned  and  executed,  the  JROC  was  discussing 
options  to  establish  a  joint  system  engineering  organization  whose  task  would  be  to 
engineer  the  capability  to  build  a  SIAP.  One  of  the  features  of  the  selected  option  was 
to  absorb  the  functionality  and  process  of  the  JIADS  IWG.  The  result  of  that  action  is 
discussed  later  in  this  report. 

ASCIET  2000  observations  included  a  significant  number  of  warfighting  capability 
shortfalls  that  prevented  establishment  of  a  SIAP  and,  as  expected,  adversely  affected 
overall  mission  performance.  In  most  cases,  ASCIET  2000  findings  were  similar  (or 
identical)  to  those  observed  during  the  tests  conducted  by  the  Joint  Air  Defense 
Operations/Joint  Engagement  Zone  (JADO/JEZ)  Joint  Test  and  Evaluation  Joint  Task 
Force  in  1992  through  1994  and  evaluations  conducted  by  ASCIET  in  1995  through 
1999.  The  data  link  architecture  that  supported  the  IADS  continued  to  experience 
known/repeat  integration  and  interoperability  anomalies,  which  resulted  in  degraded 
operational  effectiveness.  Tactical  information  and  displays  at  command  and  control 
(C2)  nodes  were  often  inaccurate,  confusing,  or  inoperable  as  a  result  of  the  following 
problem  areas: 

•  Track  dualing 

•  Track  number  changes  and  swapping  of  track  numbers 

•  Reporting  responsibility  (R2)  conflicts 

•  IFF/Selective  Identification  Feature  (SIF)  conflicts 

•  Track  ID  conflicts/ID  swapping 

•  High  net  loading  on  legacy  links 

These  deficiencies  could  be  categorized  into  the  following  areas  to  focus 
corrective  action: 

•  The  physics  of  the  operating  environment 

•  Operational  availability  of  individual  systems  and  equipment 

•  Design  or  implementation  problems  within  individual  units  or  in  the  interface 
between  units  caused  by: 

-  Adequate  specifications  but  poor  implementation  (typically  identified  as 
specific  computer  program  “bugs”) 

-  Ambiguous  or  overly  general  specifications  that  are  interpreted  differently 
by  system  or  equipment  developers  and  maintainers 
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-  Specifications  that  do  not  provide  the  intended  result  either  because  they 
are  silent  on  a  particular  critical  performance  issue  or  are  improperly  stated 

•  Tactics,  techniques,  and  procedures  (TTP)  and  training. 

Within  the  third  major  category  listed  above,  there  were  several  fundamental  or 
“structural”  root  causes  that  adversely  affected  warfighting  capability.  These  root 
causes  include: 

•  Lack  of  a  common  time  reference  across  the  force; 

•  Failure  to  achieve  a  common  geodetic  coordinate  frame  and  to  properly 
account  for  the  different  coordinate  frames  used  in  the  various  tactical  data 
links; 

•  Implementation  deficiencies  in  integration  of  inertial  navigation  systems  (INS), 
Global  Positioning  System  (GPS),  and  the  navigation  functions  of  the  Link-16 
network; 

•  Poor  tracking  performance  and  inaccurate  assignment  of  Track  Quality  (TQ), 
resulting  in  inappropriate  assumption  of  reporting  responsibility; 

•  Automatic  local-to-remote  track  correlation/de-correlation  processing 
deficiencies; 

•  Automatic  identification  processing  deficiencies;  and 

•  Connectivity  shortfalls. 

To  resolve  these  root  causes,  design  and  implementation  problems  must  be 
addressed  as  well  as  the  process  by  which  acquisition  and  engineering  decisions  are 
made  today.  If  actions  are  not  taken  to  improve  the  process  by  which  warfighting 
capability  is  fielded,  the  Department  of  Defense  is  faced  with  allocating  a  large  portion 
of  its  resources  to  fixing  problems  into  the  foreseeable  future.  With  this  in  mind,  the 
JROC  began  discussions  in  1999  to  build  a  small  organization  to  make  specific 
recommendations  for  improvement. 

The  Single  Integrated  Air  Picture  (SIAP)  System  Engineering  (SE)  Task  Force 
(TF)  was  established  to  resolve  IADS  capability  shortfalls.  In  March  2000,  the  JROC 
recommended  the  designation  of  a  lead  system  engineering  organization  to  facilitate  the 
translation  of  the  emerging  SIAP  requirement  to  a  fielded  joint  capability.  In  October 
2000,  under  the  authority  of  the  Secretary  of  Defense,  the  SiAP  SE  TF  was  established, 
chartered  by  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff,  the  Under  Secretary  of 
Defense  (Acquisition,  Technology  and  Logistics)  (USD  (AT&L)),  and  the  Assistant 
Secretary  of  Defense  for  Command,  Control  Communications,  and  Intelligence  (ASD 
(C3I))/  Department  of  Defense  Chief  Information  Office  (DoD  CIO).  The  SIAP  SE  TF  is 
a  jointly  staffed  organization,  with  proportional  representation  from  the  Services. 

Figure  1  shows  the  relationships  the  SIAP  SE  has  with  the  CINCs,  Services,  and 
Agencies.  We  are  necessarily  intimately  bound  to  the  Services. 


5 


We  have  strong  ties  to  JFCOM  (we  work  on  a  routine  basis  with  the  J6  and  J8, 
we  are  collocated  with  the  Jl&l  (Arlington)  contingent,  and  we  work  closely  with  the 
JCIET  staff). 

We  are  tied  to  the  Joint  Staff  (particularly  with  JTAMDO,  where  we  are  partners 
in  several  key  efforts  (e.g.,  JTAMD  Integrated  Architecture,  Joint  Distributed 
Engineering  Plant  (JDEP),  JTAMD  Process). 

We  are  tied  to  MDA  through  shared  interests. 

We  are  tied  to  DISA  on  JINTACCS  Process  issues  and  coordination  with  allies. 

The  Services  and  these  agencies  recognized  they  must  align  the  Department’s 
requirements  generation  and  acquisition  processes  to  overcome  warfighting  shortfalls 
observed  in  exercises,  evaluations,  and  real-world  operations.  In  2001,  the  JROC 
validated  a  series  of  capstone  requirements  documents  (CRDs)  to  focus  and  frame  the 
issues  affecting  warfighting  performance: 

•  Theater  Air  and  Missile  Defense  (TAMD) 

•  Combat  Identification  (CID) 

•  Information  Dissemination  Management  (IDM) 

•  Global  Information  Grid  (GIG) 

These  documents  provided  the  foundation  upon  which  the  SIAP  SE  Task  Force 
began  constructing  its  collaborative  system  engineering  process  for  the  purpose  of 
detecting  tracking,  reporting,  processing,  and  engaging  aerospace  objects  in  a  theater 
of  operations. 


6 


By  charter,  the  SIAP  SE  TF  is  responsible  for  the  system  engineering  necessary 
to  develop  recommendations  for  systems  and  system  components  that  collectively 
support  building  and  maintaining  a  SIAP  capabiiity. 

“The  mission  of  the  Task  Force  is  to  identify  the  most  effective  and 
efficient  means  to  achieve  a  SIAP  that  satisfies  the  warfighter  needs.  The 
SIAP  SE  will  satisfy  this  mission  by  impiementing  a  disciplined  systems 
engineering  process.  This  process  will  yield  recommendations  for  fielding 
a  SIAP,  which  will  lead  to  measurable  improvements  in  warfighting 
capability.”  [SIAP  SE  Task  Force  Charter] 

The  key  focus  of  SIAP  SE  TF  efforts  is  the  implementation  of  a  disciplined 
system  engineering  process.  This  process  yields  specific  engineering 
recommendations  for  the  purpose  of  providing  measurabie  improvements  in  warfighting 
capability.  The  SIAP  SE  TF  is  accomplishing  this  task  by  building  a  collaborative  work 
environment,  which  leverages  existing  infrastructure  and  processes.  The  Task  Force 
will  pilot  a  process  leveraging  the  strengths  of  the  existing  JTAMD  and  JINTACCS 
processes  while  expediting  system  engineering  solutions  to  warfighter  shortfalls  and  the 
eventual  achievement  of  the  objective  SIAP  capability.  The  SIAP  SE  TF  is  considering 
the  entire  spectrum  of  alternatives  (including  training  and  tactics,  techniques,  and 
procedures  (TTP))  to  make  recommendations  on  the  most  cost-effective  means  to 
achieve  the  SIAP. 
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_ Table  1:  SIAP  SE  TF  Charter  excerpts: _ 

(1)  Develop  and  maintain  a  disciplined  system  engineering  process  and  use 
that  process  to  develop  and  integrate  a  SIAP  capability.  Efforts  will  be  limited 
to  those  areas  in  the  following  subjects,  and  only  as  they  relate  to  the  SIAP: 

(a)  TAMD  BMC4I  systems 

(b)  JDN  and  systems  that  express  JDN  functionality 

(c)  JCTN  (pending  validation  of  a  JCTN  requirement). 

(d)  Other  Joint  TADILs,  networks,  advanced  concept  technology 
demonstrations  (ACTDs),  or  upgrades  as  may  be  assigned  by 
USD{AT&L)  or  ASD/C3I  and  approved  by  the  JROC. 

(4)  Focus  initial  efforts  on  identifying,  prioritizing,  and  recommending  fixes  to 
the  existing  JDN  deficiencies,  while  ensuring  these  fixes  are  on  the  path  to  an 
effective  SIAP  capability. 

(5)  Submit  recommendations  for  JDN  improvements  to  the  JTAMD  process, 

SIAP  Acquisition  Executive  (AE),  and  JROC  for  approval. 

I  (8)  Establish  the  required  collaborative  engineering  environment  (including 
simulations  and  hardware-in-the-loop  capabilities),  for  problem  investigation 
and  the  development,  testing,  and  validation  of  the  equipment  and  computer 
programs  that  build  and  maintain  the  SIAP.  Provide  feedback  from  the  test 
and  evaluation  process  to  USJFCOM  so  this  information  can  be  used  to 
refine  TTPs. 

(10)  Supported  by  the  JTAMD  process,  use  a  disciplined  system 
engineering  process  to  develop  the  system  and  technical  views  of  the  SIAP 
component  of  the  TAMD  integrated  architecture,  to  include  an  overall  time- 
phased  development  and  deployment  schedule,  ensuring  this  work  is 
consistent  with  and  supports  the  operational  views  of  the  TAMD  integrated 
architecture.  Ensure  the  work  to  define  the  system  views  is  consistent  with 
and  supports  the  common  operational  picture/common  tactical  picture  “family 
of  interoperable  operational  pictures”  initiative. _ 

The  SIAP  is  both  a  means  and  an  end.  It  is  an  enabler  for  more  effective 
warfighting  and  is  part  of  a  larger  construct  that  must  be  carefully  engineered  so  it  can 
easily  migrate  toward,  and  support,  a  coherent  tactical  picture.  As  such,  it  is  recognized 
that  the  SIAP  supports  Joint  Forces  Air  Component  Commander  (JFACC)  mission 
areas  involving  the  tactical  employment  of  airpower.  An  incremental  approach  is 
needed  to  develop  and  implement  improvements  to  command  and  control  capabilities  of 
existing  systems,  and  the  integrated  architectures  within  which  these  systems  operate, 
while  the  objective  SIAP  capability  is  being  developed. 

Figure  3  shows  the  scope  of  the  problem  the  task  force  is  chartered  to  solve. 
There  are  several  good  efforts  underway  to  ensure  RF  and  data  "interoperability". 
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Figure  2.  Boundary  Conditions 


Interoperability  is  achieved  when  warfighters  can  work  together  to  accomplish  a 
mission.  "Good  interoperability"  is  the  state  achieved  when  equipment  and  computer 
programs  work  together  to  make  the  warfighter's  task  easier.  "Poor  interoperability"  is 
the  description  used  when  the  equipment  and  computer  programs  do  not  make  the  job 
easier,  or,  in  extreme  circumstances,  make  the  job  harder. 


The  job  of  the  SIAP  SE  TF  is  to  focus  on  the  warfighter  -  to  do  the  engineering 
necessary,  in  the  aerospace  domain,  to  achieve  the  "good  interoperability"  state. 


INTEROPERABILITY 

Interoperability  requires  the  successful  achievement  of  three  progressively 
difficult  states,  as  follows: 

(1)  Achieving  information  exchange  connectivity  between  participating  entities 

(2)  Applying  the  information  exchanged  in  a  value-added  manner  in  the 
recipient’s  information  processing  systems 

(3)  Ensuring  the  end  result  is  better  when  using  the  information  than  when  not 

using  it. 

The  first  state  is  technical  interoperability.  The  second  state  is  operational 
interoperability.  The  final  state  is  mission  interoperability.  The  earlier  states  are 
necessary  (but  not  sufficient)  to  achieve  the  later  states.  An  interoperability  effort  is  not 
successful  unless  it  achieves  the  final  state.  And  achieving  this  state  requires 
substantial  integration  of  the  participating  entities.  In  other  words,  interoperability  must 
be  built  in,  not  added  as  an  afterthought.  The  fact  that  many  of  the  participating 
systems,  (as  well  as  the  interconnect  that  provides  the  interconnect  services),  are  pre¬ 
existing  /egacy  components  of  the  “want-a-be”  integrated  system,  make  integration  a 
highly  demanding  task  with  considerable  technical  risk.  Changes  to  any  one 
component  can  have  far  reaching  effects  as  it  interacts  with  the  other  members  of  the 
system-of-systems.  Fixing  one  thing  may  well  introduce  several  new  problems  because 
of  these  interdependencies  unless  a  well-disciplined  engineering  process  is  employed. 
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Achieving  SIAP  is  often  equated  to  achieving  interoperability  in  the  FoS.  This 
association  helps  highlight  the  complexity  of  the  challenge.  Interoperability  is  more  than 
radios  and  RF  waveforms.  It  is  more  than  the  standards  and  specifications.  To  achieve 
a  SIAP  (or  interoperability),  we  must  follow  a  disciplined  system  engineering  process 
aimed  at  a  specific  outcome. 

Our  approach  is  to  leverage  work  that  is  already  underway  in  the  Services. 
Because  the  Services  have  often  had  to  out-prioritize  Joint  engineering  specific  Service 
requirements,  there  wasn’t  much  to  leverage.  If  we  attempt  to  leverage  Service  system 
engineering,  we  often  tap  into  people  who  are  already  overextended  and  who  do  not 
have  experience  conducting  joint  system  engineering.  We  will  not  enter  into  an  SE&I 
contract  ~  that  wouldn't  make  life  easier,  anyway,  as  industry  has  the  same  problems 
that  we  have  with  the  Services.  A  major  hypothesis  under  consideration  by  the  Task 
Force  is  that  improvements  to  the  Joint  Data  Network  (JDN)  and  the  consideration  of  a 

Joint  Composite  Tracking  Network  (JCTN)  within  or  in  addition  to  the  JDN  is  required  to 
support  a  SIAP. 

The  product  of  the  SIAP  SE  TF  recommendations  will  be  combat-ready, 
operationally  certified  equipment  and  computer  programs  that  enable  the  warfighter  to 
build  and  maintain  a  SIAP,  and  input  to  TTP  necessary  to  operate  the  C2  components 
of  an  IADS. 

As  stated  in  paragraph  5.b  of  the  SIAP  SE  Charter, 

“The  SIAP  provides  the  warfighter  the  ability  to  better  understand  the 
battlespace  and  employ  weapons  to  their  designed  capabilities.  The  SIAP 
will  support  the  spectrum  of  offensive  and  defensive  operations  by  US, 
allied,  and  coalition  partners  in  the  airspace  within  a  theater  of  operations 
(e.g.,  attack  operations,  suppression  of  enemy  air  defenses,  air  and 
missile  defense,  intelligence  preparation  of  the  battlefield).  The  SIAP  is 
accomplished  through  a  combination  of  materiel  and  non-materiel 
improvements.” 

The  Task  Force  will  review  SIAP  related  warfighting  shortfalls  to  determine 
yvhether  there  might  be  non-materiel  solutions  which  can  be  applied  (e.g.,  solutions  that 
involve  changes/improvements  to  doctrine,  organization,  training,  leadership,  personnel, 
and  facilities).  Recommendations  for  non-materiel  approaches  are  turned  over  to  the 
appropriate  organization(s)  (i.e.,  CINCUSJFCOM  in  the  case  of  tactics,  techniques,  and 
procedure  modifications)  for  further  action. 

The  end  state  of  SIAP  efforts  for  the  warfighter  will  be  recommended 
improvements  to  deployed  systems  that  will  (1)  correct  problems  that  currently 
unnecessarily  require  operator  actions  to  ensure  accurate  and  effective  system 
operations,  (2)  augment  and/or  improve  capabilities  of  fielded  systems  to  help 
warfighters  executing  their  respective  missions,  and  (3)  insert  new  technologies  where 
appropriate  to  improve  performance,  reliability  and  robustness  in  the  operation  of 
fielded  systems  to  support  warfighter  capabilities. 
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WORKING  WITH  ALLIES 


The  SIAP  SE  TF  Charter  also  recognizes  the  importance  of  interacting  with  our 
allies  as  the  system  engineering  work  proceeds.  We  have  described  the  SIAP  SE  Task 
Force  objectives  and  approach  to  several  NATO  allies  (United  Kingdom,  Germany, 
France,  Netherlands),  but  have  not  established  the  formal  relationship  necessary  to 
describe  how  we  would  work  together  to  satisfy  mutual  interests. 

Our  primary  avenue  for  allied  cooperation  and  coordination  is  the  present  Joint 
Interoperability  of  Tactical  Command  and  Control  Systems  (JINTACCS)  process.  The 
JINTACCS  process  is  discussed  later,  along  with  a  series  of  actions  we  are  taking  in 
concert  with  U.S.  DoD  JINTACCS  process  stakeholders  to  improve  the  performance  of 
this  process.  These  Changes  in  the  JINTACCS  process  should  have  a  positive  effect  on 
allied/coalition  operations.  We  can  (and  should)  do  more. 

The  DoD  acquisition  system  requires  requirements  as  the  engine  that  drives 
development.  For  the  last  ten  years  at  least,  DoD  policy  guidance  has  stated  that 
interoperability  is  a  requirement  for  all  joint  systems,  and  that  all  C^^l  systems  are  Joint. 
Most  of  the  system  Operational  Requirements  Documents  (ORDs)  reiterate  this 
requirement.  Yet  CINCs  continue  to  complain  that  the  new  systems  they  and  their  Joint 
Force  Commanders  are  receiving  fall  short  in  delivering  interoperability  capability.  As  a 
result,  recent  changes  have  been  made  in  Joint  Requirements  System  guidance  that 
mandate  interoperability  as  a  Key  Performance  Parameter.  In  addition,  information 
exchange  requirements  (lER)  must  be  provided  to  try  to  be  more  definitive  about  exactly 
what  information  must  be  exchanged  across-systems.  But  any  effort  to  design  in 
interoperability  must  also  recognize  the  need  for  flexibility  to  accommodate  the  many 
emerging  interoperability  requirements  that  are  not  yet  quite  official.  This  area 
continues  to  be  under  estimated,  and  under  planned  as  architectures  are  created. 

As  an  example,  consider  the  creation  of  a  single  integrated  aerospace  picture.  In 
the  recent  past,  sensors  would  not  only  pass  their  track  information  up  and  down  their 
chain  of  command,  but  would  additionally  broadcast  it  over  networks  such  as  Link-1 1  or 
NATO  Link-1  to  a  larger  community  as  relevant  information.  Simple  rules  were 
established  to  minimize  duplicate  reports,  but  by  and  large  the  sensors  were  unaffected 
as  they  carried  out  their  primary  missions  for  their  chain  of  command.  The  “air  picture" 
that  resulted  was  unmanaged  and  unsupervised.  In  the  future,  a  management  function 
will  be  imposed  to  oversee  quality  and  trustworthiness  in  the  air  picture.  The  rules  for 
contributing  will  become  more  complex  and  more  adaptive.  Sensors  may  be  asked  to 
move  to  cover  gaps,  and  are  required  to  correct  data  registration  errors  before  reporting 
their  tracks.  Some  sensors  may  be  asked  to  increase  their  reporting  rates  for  selected 
objects  or  objects  about  to  be  engaged.  Other  sensors  may  shut  down  under  Emission 
Control  (EMCON)  conditions,  while  still  others  may  be  asked  to  pick  up  the  slack. 
Several  sensors  may  be  asked  to  report  instead  of  a  single  sensor  having  the  “best 
track.”  Or  information  from  a  new  airborne  intelligence  intercept  platform  may  need  to 
be  appended  to  the  track  file  and  reported  on  the  broadcast  net  for  everyone  to  use. 
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The  architecture  for  information  management  must  anticipate  these  emerging 
requirements  so  that  the  infrastructure  can  be  modified;  i.e.  plan  for  growth,  when  the 
requirements  firm  up. 

The  success  or  failure  of  interoperability  ultimately  involves  highly  specific  and 
detailed  information  about  the  characteristics  of  the  system-of-systems  and  its 
participants  and  processes.  Such  detail  is  not  apparent  at  overarching  levels.  Thus 
measuring  success  in  interoperability  is  basically  a  confidence  building  process 
involving  many  steps.  Each  step  verifies  that  the  next  level  of  detail  is  working,  and 
confidence  that  full  interoperability  will  be  achieved  progressively  grows.  But  it  never 
reaches  absolute  certainty  because  of  the  complexity  of  the  system-of-systems.  There 
are  so  many  variables  that  full  testing  is  unlikely  to  ever  be  achieved,  or  even 
attempted. 

Interoperability  “defects”  not  detected  early  become  increasingly  expensive  to  fix 
later,  as  seen  with  the  many  fixes  now  required  for  the  Link-16  infrastructure  and  its 
participating  hosts  systems  to  reposition  them  as  the  foundation  for  the  Single 
Integrated  Air  Picture  (SIAP).  Confidence  building  steps  must  be  applied  early  in 
development  to  catch  these  defects  while  they  can  still  be  fixed  at  minimum  cost. 
Building  such  confidence  includes  many  sequential  steps  such  as  architecture 
development,  requirements  analysis,  system  engineering  review,  code  walkthroughs, 
developmental  compatibility  testing  with  other  systems,  and  problem  report  root  cause 
analysis.  In  this  way  the  more  obvious  problems  can  be  discovered  early  on  and  fixed, 
leaving  the  more  subtle  problems  to  be  discovered  later  in  more  extensive 
developmental  or  certification  testing. 

In  summary,  interoperability  must  be  designed  in  from  the  beginning.  In  the  case 
binding  legacy  systems  into  a  new  system-of-systems,  this  option  is  not  available 
because  all  the  systems  have  already  been  designed  without  sufficient  consideration  of 
interdependencies  of  the  system-of-systems. 

INTEGRATION 

Integration  issues  and  risks  are  well  known  and  understood  for  individual 
platforms.  For  example,  when  a  Link-16  terminal  is  added  to  a  Battalion  command 
vehicle,  issues  of  interfacing  the  terminal  with  the  mission  computer  in  the  vehicle  must 
be  planned  and  designed.  If  the  primary  function  is  to  extract  information  being  sent 
over  Link-16  and  display  the  information,  the  integration  function  is  fairly  simple.  When 
adding  a  Link-16  terminal  to  a  helicopter,  a  fighter  aircraft,  or  a  ship  the  complexity 
grows,  and  it  is  not  uncommon  for  the  cost  of  integration  to  be  several  times  the  cost  of 
the  item  being  integrated.  If  the  information  received  results  in  changes  in  state  or 
performance  of  the  existing  weapons  system,  then  these  effects  must  be  well 
understood  and  carefully  tested.  For  example,  if  a  Link-16  terminal  passes  the 
computed  location  and  velocity  of  its  host  weapons  system  platform  to  the  weapon 
system  computer,  and  this  information  is  integrated  with  the  onboard  inertial  navigation 
system,  doppler  navigation  system,  or  GPS  system,  then  the  resulting  position  will  be 
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different  than  any  one  alone.  If  this  new  position  is  now  reported  to  others,  it  will 
correlate,  to  some  degree,  differently  than  the  original  position  when  compared  with  a 
locally  generated  radar  track.  Thus  integrating  the  Link-16  equipment  on  one  platform 
has  produced  an  effect  on  all  other  platforms.  These  are  interdependencies  -  when 
information  from  participant  “A”  causes  participant  “B”  to  behave  differently,  no  matter 
how  slight.  Thus  the  integration  issues  associated  with  the  system-of-systems  is  even 
more  daunting  that  within  a  single  platform. 

When  considering  the  creation  of  SIAP  and  the  use  of  SIAP  products  for  sensor 
and  weapons  system  management,  the  system  engineer  must  be  well  versed  in  all  the 
participating  systems.  When  designing  the  operating  modes  for  the  interconnect 
infrastructure  -  JDN  and  JCTN  services  -  there  are  further  interactions  and 
interdependencies  between  these  two  services,  over  and  above  the  participating 
weapons  systems.  Consider  the  following.  The  JDN  service  is  providing  tracks  on  two 
aircraft  that  are  closing.  While  separation  is  large,  the  single  reporting  responsibility 
concept  is  applicable,  and  the  SIAP  is  generated  using  tracks  from  one  sensor  (JDN 
services).  As  the  air  tracks  converge,  the  risks  increase  that  the  two  will  be  confused  if 
JDN  services  are  continued.  So  at  some  time  before  the  merge,  the  JDN  service  stops 
tracking  and  the  JCTN  services  take  over  -  now  using  the  information  from  all  sensors 
not  just  one.  The  increased  reporting  rate  from  these  multiple  sensors,  along  with  their 
frequency  and  spatial  diversity,  and  the  range-azimuth-elevation  measurements,  permit 
each  aircraft  to  be  tracked  with  much  higher  resolution  and  confidence.  And  during  the 
time  they  are  operating  in  close  proximity  JCTN  services  continue  to  prevail.  When  one 
is  shot  down,  or  when  they  diverge  again,  the  accuracy  of  JCTN  is  no  longer  required 
by  the  community  of  users,  and  the  JCTN  drops  the  track  and  JDN  again  takes  over. 
This  example  illustrates  the  interdependencies  between  the  two  providers  of  track 
services  -  JCTN  and  JDN.  It  also  indicates  that  the  two  concepts  must  be  developed  in 
lock  step  in  order  for  them  to  be  full  compliments  to  each  other. 

Thus  it  is  clear  that  the  creation  of  an  effective,  efficient  and  responsive  system- 
of-systems  to  support  SIAP  is  highly  complex  and  requires  a  rigorous  and  disciplined 
system  engineering  process  to  guide  it  to  success. 

SYNCHRONIZATION 

If  the  above  system-of-system  attributes  were  further  complicated  by  participants 
placing  demands  on  the  complex  that  are  time  variant,  this  introduces  additional 
interdependencies,  especially  with  the  demands  are  conflicting.  For  example,  envision 
a  PATRIOT  unit  committed  to  engage  an  approaching  threat  cruise  missile  at  the  same 
time  a  nearby  naval  ship  is  preparing  to  engage  a  high  altitude  threat.  Both  weapons 
systems  ask  for  SIAP  support  requesting  track  updates  at  a  one-second  rate.  What  if 
the  available  taskable  radar  resources  don’t  have  enough  power  to  do  both  jobs?  How 
will  the  available  resources  be  used  in  the  best  way  to  support  both  customers?  This  is 
one  example  of  synchronization  where  the  supporting  SIAP  resources  must  be  time 
phased  in  their  support  because  there  isn’t  enough  to  do  both  jobs  at  the  same  time. 
This  introduces  even  more  complexity  in  system-of-systems  design  and  operation. 
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Another  example  of  synchronization  involves  the  fielding  of  the  system-of- 
systems.  Imagine  a  future  capability  to  achieve  time  slot  reallocation  for  Link-16.  If  all 
participants  join  in  the  process  at  the  same  time  it  works  well.  But  if  one  of  two  does 
not,  the  benefits  quickly  evaporate.  Thus  in  many  cases  it  is  essential  to  deploy  an 
attribute  simultaneously  across  the  force  structure,  since  if  everyone  does  not 
participate  the  benefits  are  diminished.  This  requires  cross-program  synchronization, 
something  that  is  not  at  all  easy  to  achieve  given  the  independent  development  cycles 
of  participating  systems.  On  the  other  hand,  if  we  wait  until  the  last  system  is  capable  to 
activate  a  new  capability,  we  cannot  capture  any  of  the  benefits  for  the  earlier  systems. 
We  have  wasted  any  investment  in  accelerating  the  fielding  if  just  a  few  are  delayed. 

A  final  form  of  synchronization  is  the  deployment  sequencing  of  systems 
delivered  to  the  theater.  The  design  approach  must  be  as  insensitive  as  possible  to  the 
reality  that  not  all  participating  systems  will  arrive  in  theater  at  the  same  time.  The  early 
systems  must  be  able  to  constitute  a  significant  increment  of  capability  in  the  absence 
of  all.  And  the  design  must  permit  each  new  arrival  to  “plug"  into  the  system-of-systems 
without  upset.  The  benefits  of  each  new  addition  must  be  immediately  realized  by  all 
participating  users. 

There  is  no  central  focus  for  S&T  activities  that  relate  to  the  Theater  Air  and 
Missile  Defense  mission.  This  results  in  additional  gaps,  overlaps,  and  conflicts,  as 
there  is  no  organized  way  to  share  information  and  align  efforts.  As  a  result,  we  miss 
opportunities  for  collaborative  work,  and  have  a  lower  probability  of  transitioning 
promising  technologies  into  production  and  fielding.  Many  good  ideas  fail  to  achieve 
critical  mass. 

There  is  a  related  problem  with  Advanced  Concept  Technology  Demonstrations. 
Each  ACTD  should  be  focused  on  helping  to  shape  operational  requirements,  and 
should  be  aimed  at  specific  opportunities  for  transition  to  production. 

In  the  next  section  of  this  report,  we  discuss  the  progress  we  have  made  in 
engineering  the  SIAP  and  general  plans  to  complete  the  actions  required  by  the 
Charter. 
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2.  PROGRESS  AND  GENERAL  PLANS 


Much  of  our  current  Task  Force  activity  follows  a  traditional  project  management 
approach.  Projects  are  often  characterized  by  time  and  cost  constrained  efforts, 
involving  complex  system  developments.  Our  efforts  have  focused  on  three  major 
components  of  the  system  engineering  process:  people,  processes  and  products.  The 
job  is  complex,  involving  multiple  systems,  across  competing  programs,  services,  joint 
organizations,  and  diverse  mission  areas.  In  addition,  we  must  coordinate  change 
among  existing  and  new  concepts  and  systems,  within  tight  budget  constraints. 

Our  success  can  only  be  achieved  through  a  highly  motivated  collaborative  team 
adhering  to  well-understood  and  disciplined  processes  which  produce  well-defined 
products.  The  successes  of  our  nation's  greatest  technological  efforts  including  the 
Manhattan  Project,  Polaris,  Apollo,  and  naval  nuclear  propulsion  program  can 
characteristically  be  traced  to  people,  processes  and  products.  We  also  believe  that 
today’s  warfighting  shortfalls  can  ultimately  be  traced  to  deficiencies  in  one  or  more  of 
these  components.  “When  technical  systems  fail,  ...outside  investigators  consistently 
find  an  engineering  world  characterized  by  ambiguity,  disagreement,  deviation  from 
design  specifications  and  operating  standards,  and  ad  hoc  rule  making”^ 

DoD  leadership  concluded  that  a  joint  system  engineering  approach  was 
required  to  address  this  situation.  Further,  the  DoD  leadership  recognized  that  a 
significant  investment  was  required  to  realize  the  potential  that  could  be  obtained  by 
networking  existing  systems. 

The  SIAP  SE  Task  Force  is  engaged  on  two  broad  fronts.  First,  we  are  charged 
with  "fixing"  existing  problems.  This  involves  characterizing  the  problem,  developing 
and  analyzing  candidate  solutions  for  those  problems,  and  making  recommendations  to 
the  Services  regarding  implementation.  This  is  akin  to  fire  fighting  -  putting  scarce  and 
valuable  resources  where  they  can  best  arrest  a  bad  situation  and  minimize  damage. 
The  second  front  is  focused  on  putting  the  department  on  a  sound,  joint  system 
engineering  path.  As  long  as  there  are  joint  warfighting  requirements,  the  department 
will  need  an  activity  to  make  recommendations  to  translate  these  requirements  into 
equipment  and  computer  programs.  Doing  this  job  well  will  significantly  reduce  the 
resources  consumed  by  scrap  and  rework.  This  effort  is  akin  to  fire  prevention  - 
investing  time  and  energy  into  avoiding  costly  problems. 

We  have  been  challenged  with  developing  a  disciplined  system  engineering 
process  while  providing  recommendations  for  SIAP-related  improvements.  We  are 
therefore  building  the  bridge  as  we  try  to  traverse  the  abyss.  What  is  particularly 
daunting  in  both  these  efforts  is  the  cultural  and  infrastructural  improvements  required  of 
both  tasks.  No  standardized  process  exists  today  to  support  joint  collaborative  system 
engineering.  Our  efforts  add  order  to  the  chaos.  Our  approach  standardizes 
collaborative  teams,  products,  and  processes  to  support  focused,  repeatable,  and 


^  Vaughan,  D.  (1996).  The  Challenger  Launch  Decision,  Risky  Technology,  Culture,  and  Deviance  at 
NASA.  Chicago:  University  of  Chicago  Press. 
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rigorous  analysis  to  effect  change.  Within  budgeted  FY01  funding,  the  task  force  has 
made  significant,  measurable  progress  in  several  key  areas  as  we  focus  on  people, 
products  and  process. 

This  section  highlights  our  efforts  to  establish  an  infrastructure  which  effectively 
uses  high-quality  people  and  processes  to  develop  high-quality  products.  This 
infrastructure  is  required  to  support  the  “disciplined  system  engineering  process"  we 
were  tasked  to  develop. 

2.1.  TEAM  FORMATION 

We  are  challenged  to  build  a  system  engineering  leadership  and  management 
team,  composed  of  professionals  with  diverse  technical  and  leadership  background. 
There  are  very  few  “joint"  experts  whose  experience  base  supports  a  broad 
understanding  of  the  IADS  and  operational  integration  issues  associated  with  SIAP 
deficiencies.  In  addition,  we  are  required  to  remain  organizationally  “lean”  leveraging 
the  personnel  provided  to  us  from  the  services  “out-of-hide".  The  diverse  nature  of  each 
engineering  issues  requires  representation  not  only  from  multiple  players  across  Joint 
organizations  and  Services,  but  from  within  a  particular  Service  and  organization.  We 
have  however,  built  the  initial  framework  for  a  joint,  collaborative  system  engineering 
team.  This  team  recognizes  that  joint  collaboration  is  as  much  about  trust  and 
confidence  as  it  is  about  capability.  Our  efforts  have  leveraged  previous  and  on-going 
work  done  by  the  CINCs,  services,  and  agencies  (C/S/A).  We  have  defined  a  number 
of  system  engineering  teams  and  working  groups  composed  of  subject  matter  experts 
(SMEs)  from  the  services  and  joint  organizations  who  are  building  the  various 
components  of  our  processes. 
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Table  2:  Personnel 


As  of 

mid-May  02 

Task  Force  Staff 

Army 

Navy 

Marine 

Corps 

Air 

Force 

3* 

6* 

Military 

5 

3 

8 

Contractor 

4 

0 

Total 

7 

11 

3 

8 

Allocation 

9 

9 

3 

9 

Delta 

-2 

+2 

0 

-1 

*lncludes  borrowed  military  manpower 


The  size  and  structure  of  the  Task  Force  is  designed  to  ensure  that  most  of  the 
system  engineering  work  is  done  by  the  Services  in  the  field.  We  have  learned  a  great 
deal  about  how  this  arrangement  can  be  made  to  work.  We  have  been  working  through 
the  issues  that  can  be  expected  by  coupling  a  Joint  system  engineering  effort  to  existing 
Service  system  engineering  efforts. 

We  have  built  our  collaboration  effort  on  the  concept  of  achieving  “reasonable 
consensus”  among  participants.  Reasonable  consensus  ensures  each  view  is  fairly 
represented  and  considered.  The  decision  reflects  what  the  joint  group  believes  is  the 
most  reasonable  approach.  Most  notable,  is  the  consensus  reached  through  the 
process  by  which  the  SIAP  attributes  were  defined.  The  Services,  JTAMDO,  MDA, 

JITC,  JCIET,  and  JFCOM  have  endorsed  these  metrics  as  the  assessment  measures 
for  characterizing  the  SIAP. 

To  offer  meaningful  joint  engineering  recommendations,  a  standardized 
collaborative  analysis  process  must  occur.  This  joint  analysis  process  includes: 
analysis  planning,  data  collection,  forensic  analysis,  and  reporting.  The  JIADS  IWG 
provided  the  first  integrated  forum  by  which  joint  evaluation  of  IADS  performance  could 
be  achieved.  The  JIADS  IWG  established  a  collaborative  joint  environment  for  the 
purpose  of  conducting  cross-platform  forensic  (root-cause)  analysis  in  support  of 
ASCIET  exercises.  The  JIADS  IWG  has  been  significantly  successful  in  identifying 
root-causes  of  joint  warfighting  shortfalls  and  recommending  solutions  for  many  of  those 
shortfalls.  Following  the  JIADS  IWG  model,  we  have  defined  a  collaborative  SIAP 
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analysis  process.  This  process  compares  results  and  links  critical  experiments  from 
multiple  T&E  events. 

SIAP  Analysis  Team  (SAT) 

The  SAT  is  a  SIAP  SE  led  joint  analysis  team  composed  of  CINC/Service/ 
Agency  (C/S/A)  IADS  analysis  experts.  The  mission  of  the  SAT  is  to  provide  cross¬ 
service  IADS  analytical  expertise  to  support  SIAP-related  system  engineering  decision¬ 
making.  This  mission  includes:  analysis  planning,  data  collection  support,  evaluative, 
predictive  and  prescriptive  analysis,  and  after-actions  required  to  system  engineer 
improvements  to  the  IADS.  The  SAT  does  not  replace  existing  service  and  agency 
analysis  groups.  Rather,  its  purpose  is  to  act  as  an  standard-setter  for  comparing 
results  from  SIAP-related  live  exercises/critical  experiments,  hardware-in-the-loop 
(HWIL),  operator-in-the-loop  (OITL),  and  other  modeling  and  simulation  (M&S)  events  to 
support  the  collaborative  system  engineering  decision-making  process.  Products  of  the 
SAT  will  include  planning  reports  and  schedules;  documented  root-cause  analyses, 
lessons  learned,  IADS  capabilities  and  limitations,  and  documented  results  and 
engineering  recommendations. 

The  SAT  is  modeled  after  collaborative  nature  of  the  JIADS  IWGs  but  expands 
the  JIADS  IWG’s  responsibilities  to  support  SIAP-related  analysis  other 
events/exercises  including:  Roving  Sands,  Foal  Eagle,  Virtual  Warfare  Center,  Joint 
Distributed  Engineering  Plant,  Joint  National  Test  Facility,  etc.  The  SAT  is  also 
responsible  for  assessing  the  utility  of  Service  and  Joint  M&S,  HWIL,  and  OITL  tools  in 
support  of  SIAP  related  efforts.  Such  assessment  include:  determining  the  availability 
of  tools,  schedule  coordination,  IV&V  pedigree,  required  upgrade,  data  formats, 
potential  for  federation,  etc. 

The  SAT  will  support  the  disciplined  SIAP  system  engineering  process  by 
standardizing  all  aspects  of  analysis  required  to  support  selected  exercises/events.  The 
SAT  must  perform  overarching  planning,  and  scheduling  of  M&S  and  live  evaluation 
resources  to  support  SIAP  system  engineering  requirements.  The  SAT  will  accomplish 
this  overarching  planning  through  collaborative  overall  objectives  for  events  and 
exercises.  Events  considered  must  be  scheduled  such  that  appropriate  support  may  be 
rendered  from  SAT  membership.  Initial  consideration  must  be  given  to  the  overall 
purpose  of  events,  the  participants,  and  most  importantly  the  availability  of  high  fidelity 
ground-truth  data.  Once  the  determination  to  support  an  exercise/event  is  made  the 
SAT  will  follow  a  four-phased  process  consisting  of:  1)  event  planning,  2)  conducting  the 
event  3)  analysis,  and  4)  reporting. 

Event  planning.  During  this  phase,  the  SAT  will  emphasize  the  “What,  Who, 
When,  Where”  aspects  of  the  evaluation  effort.  The  first  step  is  to  determine  exactly  the 
end  product  and  the  scope  of  the  effort.  This  will  depend  largely  on  the  exercise/event 
and  whether  or  not  any  SIAP-related  improvements  have  been  incorporated  into  the 
systems  that  are  expected  to  participate.  Analysis  efforts  should  be  focused  on 
assessing  the  warfighting  benefits  attributable  to  improvements  to  systems  using  an 
established  set  of  criteria  in  addition  to  determining  root-cause  for  any  problems 


18 


observed.  The  focus  and  the  products  of  that  focus  must  be  documented.  For  this 
purpose  the  product  is  a  list  of  potential  actions,  which  support  improvements  to 
warfighting  capability.  The  path  to  defining  this  product  includes  measuring  existing 
capability,  comparing  those  measurements  with  required  capability  as  defined  in 
requirements  documents,  and  understanding  deltas  between  the  two  by  conducting 
root-cause  analysis  of  the  shortfalls.  The  problem  space  must  be  bounded  to  maximize 
resources.  This  bounding  includes  identification  of  types  of  warfighting  shortfalls  of 
interest,  mission  areas,  and  operational  context.  In  addition,  for  the  M&S  environments 
the  SAT  must  identify  the  appropriate  tools  to  use  to  support  specific  improvement 
objectives  and  the  potential  to  federate  tools  to  support  evaluation  of  warfighting  benefit. 

Event  conduct.  The  type  and  amount  of  involvement  in  an  event  by  the  SAT  will 
depend  on  the  overall  objectives  of  the  analysis  effort.  For  Block  improvement 
assessments  and  exercise/event  performance  evaluations,  the  SAT  will  operate  both  as 
an  oversight  body  with  coordination  responsibility  for  federating  tools  required  to  support 
the  SIAP  SE  decision  making  process  and  provide  appropriate  resources  to  support 
event/evaluation  conduct.  For  root-cause  or  assessment  of  selected  live  events  and 
major  M&S/HWIL/OITL  venues  the  SAT  will  not  only  analyze  existing  data 
collection/extraction  activities  but  ensure  that  the  SIAP-related  data  collection 
requirements,  as  detailed  in  the  (Data  Management  and  Analysis  Plan)  DMAP,  are 
being  met.  The  SAT  will  also  be  responsible  for  supporting  on-site  analysis  for  SIAP- 
related  issues.  The  purpose  of  this  on-site  analysis  is  to  isolate  issues  either  for  rapid 
(one/two  day)  response,  (so  that  immediate  changes  to  tactics,  set-up,  or  procedures 
can  be  implemented  for  the  remainder  of  the  event),  or  for  post-event  analysis.  SAT 
representatives  will  also  be  responsible  for  the  generation  and  disposition  of  Test 
Observation  Reports  (TORs)  that  are  generated  during  the  selected  events.  A  TOR 
database  will  be  developed  and  maintained  by  the  appropriate  TOR  database  manager. 
SAT  representatives  will  periodically  review  the  state  of  TORs.  Events  of  Interest  (EOl) 
will  be  compiled  during  live  exercises  and  a  priority  TORs  list  to  guide  post-test  analysis. 
Potential  issues  will  be  derived  from  debriefings  and/or  observer  notes. 

Analysis.  The  analysis  efforts  are  highly  dependent  on  the  type  of  event,  the 
purpose  of  the  event,  and  the  analysis  requirements.  The  DMAP  shall  delineate  the 
responsibilities  of  the  SAT.  The  analysis  phase  will  be  driven  by  the  overall  objectives 
for  the  test.  The  SIAP  Integrated  Assessment  Plan  (lAP)  will  delineate  overarching 
SIAP-related  analysis  objectives.  The  SAT  must  identify  the  candidate  M&S/HWIL/OITL 
and  live  exercises  required  to  support  the  engineering  decision-making  process.  The 
lAP  must  establish  the  roadmap  for  integrating  the  individual  analyses  resulting  from 
use  of  the  designated  analysis  tools.  During  live  exercises  and  selected  HWITL/OITL 
two  important  factors  must  be  considered  for  the  analysis  efforts.  (1 )  Co-location  of  the 
data  analysis  team  and  (2)  the  capability  to  conduct  replay  analysis.  Co-located, 
collaborative  analysis  efforts  are  key  for  successful  and  insightful  evaluation  of  SIAP- 
related  events.  The  capability  to  overlay  time-space-position-information  with  weapon 
system  data  and  C3I  data  provides  a  valuable  analysis  methodology  for  root-cause 
analysis.  For  live  events  and  selected  HWIL/OITL  events  post-event  data  analysis 
consists  of  initial  on-site  analysis  supported  by  SAT  representatives  over  a  period  of 
days,  followed  by  “Team”  data  analysis  meetings  scheduled  approximately  three  weeks 
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after  the  test  event.  Between  “Team”  data  analysis  meetings,  the  SAT  will  coordinate 
the  conduct  of  follow-up  analysis  at  C/S/A  sites  for  evaluating  platform-specific  TORs 
and  EOls  and  assisting  in  roll-up  analysis  of  the  documented  performance  assessment 
measures. 

Live  exercise  post  event  analysis  will  be  performed  in  accordance  with  the  goals 
of  the  DMAP.  These  goals  may  include: 

1 .  Isolation  of  immediate  issues 

2.  Resolution  of  EOls 

3.  Resolution  of  TORs 

4.  Recommended  corrective  action,  and 

5.  Evaluation  of  capability  using  documented  assessment  measures 

Root  cause  analysis  Is  accomplished  though  categorization  of  issues  as  defined 
by  the  Lessons  Learned  Database  process.  The  category  bins  are: 

1 .  “Bugs”-Specific  system  related  issues  usually  caused  by  a  failure  to  properly 
implement  a  requirement 

2.  “Structural”  root  cause — Issues  shared  by  two  or  more  systems  usually  caused 
by  improperly  derived  or  omission  in  a  requirement 

3.  Tactics,  Techniques  or  Procedural  (TTP)  issues  including  training 

4.  Not  repeatable  issues 

Further  characterization  of  “structural”  issues,  require  the  decomposition  of  these 
issues  into  lower-level  "bins.”  Such  bins  include  specific  system  functionality,  time 
synchronization;  navigation;  detection  and  tracking;  connectivity;  data  registration; 
automatic  local-to-remote  track  correlation;  reporting  responsibility;  identification 
information  processing;  and  display.  The  SAT  will  be  responsible  for  ensuring  such 
binning  is  accomplished  through  the  appropriate  C/S/A  experts.  Issues  will  be  identified 
as  follows: 

1.  Issue  name 

2.  Issue  description 

3.  Warfighting  impact  expressed  in  operational  terms 

4.  Identified  work-around 

Actions.  All  identified  issues  shall  be  documented  in  the  SIAP  Lesson  Learned 
Database.  For  live  events  issues  will  be  dispositioned  as  follows 
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1 .  "Bugs"  are  returned  to  service-specific  program  offices  for  action 

2.  "Structural"  Theater  Air  Warfare  issues  are  forwarded  to  the  SIAP  SETF  for 
prioritization,  engineering  analysis,  and  solution  recommendations 

3.  Clearly  defined  TTP  must  be  returned  to  the  warfighting  community  i.e., 
JFCOM  for  action. 

For  M&S  related  events,  the  SIAP  SETF  will  coordinate  and  support  joint 
warfighting  analysis.  Such  analysis  shall  be  in  accordance  with  the  SIAP  SETF 
Integrated  Assessment  Plan,  and  will  leverage  previous  M&S,  HWIL,  OTIL  and  Live 
evaluation  data.  The  SAT  will  coordinate  integrated  analysis  efforts  utilizing  joint  and 
service-specific  analysis  organizations  and  tools. 

All  analysis  efforts  will  be  documented  in  formal  technical  reports,  coordinated 
through  the  appropriate  C/S/A's. 


Recommendation:  Endorse  the  SIAP  Analysis  Team 
as  the  oversight  body  for  planning,  coordinating, 
analyzing  and  reporting  SIAP  performance  at  all  SIAP 
related  T&E  events.  ^ 


2.2.  DISCIPLINED  SYSTEM  ENGINEERING  PROCESS 

The  SIAP  SE  Task  Force  Charter  directed  the  implementation  of  a  “disciplined 
system  engineering  process”  to  “achieve  a  SIAP  that  satisfies  the  warfighter  needs" 

The  discipline  in  the  system  engineering  process  flows  from  standardized  policies, 
procedures,  and  processes,  which  support  the  capability  to  perform  rigorous  and 
repeatable  engineering  analyses  and  other  activities.  Three  important  elements  of 
rigorous  engineering  analyses  include  the  capabilities  to:  (1 )  evaluate  present  capability 
to  understand  differences  between  current  and  the  required  capability,  (2)  prescribe 
improvements  to  meet  requirements,  and  (3)  predict  performance  based  on  those 
improvements.  The  “discipline"  in  the  analysis  is  accomplished  through  clear, 
consistent,  and  repeatable  standards.  These  standards  include  the  use  of  common 
methods,  tools,  architectures,  operational  context,  and  metrics  to  perform  meaningful, 
repeatable,  and  operationally  representative  analysis. 

The  block  improvement  process  addresses  specific  JDN  issues,  and  identifies 
warfighting  capability  shortfalls  in  a  prioritized  order.  The  first  set  of  warfighting 
shortfalls  have  been  characterized  as  “Block  0.”  The  effort  to  deal  with  this  first  set  of 
issues  provides  a  “pilot”  for  development  of  disciplined  processes,  of  ever-expanding 
complexity  to  achieve  an  objective  SIAP  capability  as  defined  by  JROC-validated 
requirements. 

We  have  used  our  Block  0  efforts  to  begin  building  the  disciplined  system 
engineering  process  needed  to  realize  the  level  of  performance  required  by  the  TAMD 
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and  CID  CRDs.  The  SIAP  SE  has  identified  mutually  supporting  efforts  to  address 
near,  mid  and  far-term  improvements  to  the  JDN,  while  implementing  the  required 
process  and  structural  discipline  to  build  an  objective  SIAP  capability. 

We  recognize  the  complexity  of  building  a  disciplined  system  engineering 
process  within  a  complex  system  of  systems  (SoS)  environment.  Integrated 
development  normally  starts  from  the  ground  up.  System  reliability  traditionally  is 
achieved  through  rigid  architecture  definitions  and  interface  standards  combined  with  an 
uncompromising  adherence  to  technical  requirements.  Unfortunately,  the  SIAP  SE 
effort  must  build  reliability  into  an  IADS  comprising  a  mix  of  legacy  and  new 
development  systems.  This  imposes  the  significant  challenge  of  building  infrastructure 
and  discipline  after  the  fact.  Dealing  with  this  challenge  invariably  leads  to  “interfaced” 
vice  “integrated”  systems. 

PROCESS 


- - ►  PROCESS  OUTPUTS 

Figure  3.  IEEE  Std  1220-1998:  The  System  Engineering  Process 


Recommendation:  Reduce  Service 
specific  “point”  solutions  which  lead  to 
interfacing  vice  integration  of  systems. 
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Our  disciplined  approach  is  based  IEEE  Std  1220  -1998  System  Engineering 
standard.  Our  approach  is  to  answer  five  fundamental  questions: 

1.  What  is  the  technical  requirement  as  manifested  in  the  CRD  KPPs? 

2.  What  is  the  current  IADS  capabilities-system  to  warfighter  benefit? 

3.  What  is  the  delta  to  current  capabilities  and  requirements? 

4.  What  system  improvements  alternatives  will  close  the  gap? 

5.  What  are  the  cost,  schedule  and  performance  trades  to  make  required 
recommendations? 

To  answer  these  questions,  the  analytic  efforts  must  support  the  System  Analysis 
portion  of  figure  3.  Our  tools,  processes  and  teams  support  the  conduct  of: 
requirements  trades  studies  and  assessments  to  ensure  we  understand  the  warfighting 
requirements  we  are  trying  to  meet;  functional  trade  studies  and  assessments  to 
parametrically  map  IADS  functionality  from  system  levels  to  the  warfighting 
requirements:  and  design  trades  and  assessments  to  determine  specific  system 
improvement  alternatives  to  meet  functional  requirements. 

Our  analytical  goals  are  to  institutionalize  clear  and  deterministic  assessment 
measures  and  assessment  processes  based  on  joint  requirements.  Joint  requirements 
define  integrated  system  architecture,  it  is  the  system  and  technical  views  of  this 
architecture  that  support  engineering.  These  standards  support  the  use  of  common 
tools,  processes  and  collaborative  teams  across  test  and  evaluation  venues. 

The  complexity  of  the  SIAP  environment  necessitates  a  disciplined  system 
engineering  process  by  which  capability  assessments  of  system  integration  can  be 
made  and  overall  performance  can  be  baselined.  Processes  such  as  the  Joint 
Interoperability  of  Tactical  Command  and  Control  Systems  (JINTACCS),  Service  and 
Joint  interoperability  certification,  and  Independent  Operational  Test  and  Evaluation,  all 
provide  methods  by  which  we  can  evaluate  how  well  systems  operate  within  service 
mission  areas  and  in  the  joint  context.  Unfortunately,  the  Joint  evaluative  processes 
and  systems  are  compartmentalized.  These  processes  have  not  been  integrated  to 
provide  a  complete,  end-to-end,  process  that  supports  multiple  layers  of  interoperability 
evaluation.  It  is  only  through  capability  improvement  process  that  includes  the 
integration  of  the  various  configuration  control,  management,  and  certification 
processes  identified  above  that  the  DoD  can  consistently  and  reliably  field  warfighting 
capable  systems.  Various  land-based  tools  along  with  live  exercises  must  be 
analytically  linked  in  a  reliable  and  repeatable  process  that  provide  the  vehicle  by  which 
an  end-to-end  joint  certification  effort  can  be  maintained.  Joint  certification  must  go 
beyond  message  standard  compliance.  Joint  certification  must  be  based  on  not  only 
how  well  units  send  and  receive  information,  but  must  be  based  on  how  well  systems 
process  and  display  the  information  received.  This  requires  “final  exam”  or  series  of 
“final  exams”  of  the  system  of  systems.  We  have  a  number  of  HWIL,  OITL,  and  live 
events  available  to  comprise  an  IADS  “final  exam.”  The  “final  exam”  should  be  based 
on  standardized  metrics,  scenarios,  and  grading  criteria.  The  “final  exam”  must  be 
based  on  deployable  configurations  of  the  systems  of  systems. 
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These  efforts  must  include  the  following  key  requirements: 

•  Common  warfighting  scenarios  and  mission  engagement  vignettes  used 
across  service  and  in  joint  evaluations 

•  Common  MOEs,  attributes  and  MOPs  by  which  to  quantify  performance  and 
capability 

•  The  SIAP  component  of  the  TAMD  Integrated  Architecture,  reflecting 
deployable  systems,  equipment  and  computer  programs 

•  A  Joint  analysis  team  for  “honest  broker”  data  reduction  and  analysis 

•  Linked  results,  such  that  outputs  of  one  tool  or  venue  may  be  analytically 
linked  to  inputs  of  other  tools  or  venues  to  compare  and  contrast  results 

•  A  single  Joint  authority  that  will  enforce  the  above  requirements  and  can  direct 
that  improvements  to  platform  and  standards  be  implemented  before  systems 
can  deploy.  In  addition,  this  authority  must  empower  the  appropriate 
organization  to  enforce  configuration  control  on  system  computer  programs,  to 
ensure  that  systems  are  truly  certified  interoperable  before  deployment. 

Recommendation:  Support  development  of  a 
capability  assessment  approach,  with  a  single  joint 
authority. _ 


2.2.1.  Common  Reference  Scenarios 

Scenario-based  design  is  recognized  as  a  significant  tool  to  support  the  system 
engineering  process.  “Scenarios  afford  multiple  views  of  an  interaction,  diverse  kinds  of 
and  amounts  of  detailing,  helping  developers  manage  the  many  consequences  entailed 
by  any  given  design...”  [Carroll] .  In  addition,  “...scenarios  promote  work-oriented 
communication  among  stakeholders,  helping  to  make  design  activities  more  accessible 
to  the  great  variety  of  expertise  that  can  contribute  to  design,  and  addressing  the 
challenge  that  external  constraints  designers  and  clients  often  distract  attention  from  the 
needs  and  concerns  of  the  people  who  will  use  the  technology”  [Carroll]. 

We  are  extending  the  concept  of  scenario-based  design  to  support  the  contextual 
representation  of  the  SIAP  operational  concept.  A  representative  operational  context 
supports  evaluation  of  IADS  capabilities  in  real-world  replicated  settings.  The 
operational  context  provides  a  foundation  for  the  development  of  the  Operational  View 
of  the  TAMD  Integrated  Architecture. 

Our  disciplined  process  is  based  on  standardization  of  key  simulation  tools, 
providing  common  reference  frames  for  “apples-to-apples”  comparisons.  In  addition,  to 
support  the  work-oriented  communication  cited  above,  common  reference  frames 
support  Joint  evaluation  of  the  IADS  in  both  the  simulated  and  live  environments.  One 
of  these  standardized  tools  is  the  establishment  of  a  set  of  Common  Reference 
Scenarios  (CRSs). 
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We  have  defined  three  CRSs  based  on  Defense  Planning  Guidance.  These 
CRSs  are  composed  of  digitally  scripted  red  and  blue  force  interactions  in  operationally 
relevant  time-phased  campaigns.  These  interactions  are  dependent  on  operationally 
detailed  engineering  vignettes  (under  development),  flowing  from  the  force  level 
scenarios.  The  engineering  vignettes  provide  stressing  limited  scope  platform 
engagements  which  can  be  applied  to  the  Modeling  and  Simulation  (M&S),  Hardware 
In  the  Loop  (HWIL),  Operator  In  The  Loop  (OITL)  and  open  air  test  exercises  to  support 
stressing  IADS  assessments  In  realistic  and  repeatable  engagements.  Within  this 
framework,  evaluations  of  SIAP-system  enhancements  and  the  resulting  impact  on 
warfighter  capabilities  from  the  system/unit  through  the  campaign  level  may  be 
quantified.  The  operational  framework  will  contain  the  definition  of  requirements  and 
support  the  development  and  certification  of  system  functional  baselines. 

We  are  gaining  joint  endorsement  of  SIAP  CRSs  through  the  JTAMD  Operational 
Architecture  Roadmapping  (OAR)  Working-level  Integrated  Product  Team  (WIPT). 

While  Red  Force  interactions  receive  formal  endorsement  through  the  Defense 
Planning  Guidance  process,  the  OAR  WIPT  process  provides  the  best  opportunity  for 
Service  collaboration  and  eventual  Joint  force  endorsement  on  the  collective  SOS  Blue 
Force  lay-downs  associated  with  each  CRS. 


Recommendation:  institutionalize  SIAP  Common 
Reference  Scenarios  across  DoD  as  the  standardized 
operational  context(s)  for  characterizing  SIAP 
performance. _ 


We  recognize  that  we  cannot  script  every  possible  operational  employment  of 
our  forces  against  every  possible  adversary.  We  do  believe  that  the  "joint"  community 
must  agree  upon  a  limited  number  of  CRSs.  DoD  has  no  centralized  capability  to 
standardize  both  Red  and  Blue  force  scripted  scenarios.  While  scripting  of  Red  forces 
is  well  organized.  Blue  force  scripting  has  in  the  past  been  left  to  individual  services  for 
very  specific  and  limited  evaluation  purposes.  No  joint  organization  has  responsibility 
for  approving  combined  dynamic  interactions  of  Red  and  Blue  forces  in  operational 
representative  CRSs.  This  severely  limits  DoD  in  developing,  understanding  and 
documenting  joint  warfighting  requirements. 

2.2.2.  Analytic  Tools 

Standardized  evaluative  tools  form  the  basis  for  repeatable  analysis.  The 
Department  invests  significant  resources  in  test  and  evaluation  tools  annually.  To 
optimize  this  investment,  system  of  system  (SoS)  analysis  must  utilize  various 
assessment  venues  in  conjunction  with  live  exercise  evaluations  to  reduce  development 
risk.  M&S,  HWIL,  and  OITL  venues  support  evaluation  of  specific  components  of  the 
Family  of  Systems  (FoS)  from  system  specific  to  integration  performance  perspectives. 
The  objectives  of  our  efforts  are  to  leverage  existing  tools  to  the  maximum  extent 
practical. 
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Many  M&S/HWIL/OITL  tools  exist  today.  These  tools  are  used  by  the  Services 
and  Joint  organizations  to  provide  an  analytical  basis  for  design,  development  and 
evaluation  of  TAMD  systems.  System  specific  and  joint  integrated  tools  provide  a  broad 
range  of  analytical  capabilities  at  various  measurement  levels.  By  federating  models 
and  analytic  constructs  to  support  parametric  measurements  across  all  levels,  variations 
in  system  functional  performance  can  be  traced  to  force  level  capability  improvements. 
Each  tool  supports  analysis  for  a  particular  facet  of  the  Family  of  Systems  (FoS).  No 
one  tool  models  all  aspects  of  the  IADS  functionality  from  systems  performance  to 
warfighting  capability.  As  described  earlier,  we  ultimately  desire  a  “final  exam”  of 
integrated  system  performance  at  live  evaluations  and  exercises  such  as  JCIET  Roving 
Sands,  and  OPEVAL. 

No  one  tool  can  measure  the  “interoperability”  of  the  IADS.  In  fact,  measuring 
“interoperability”  is  a  misnomer.  Interoperability  in  and  of  itself  can  only  be  traced  to 
quantifiable  measures,  which  provide  an  indication  of  how  well  systems  have  been 
integrated. 

We  are  building  a  “tool  kit”  of  required  analytic  tools  to  support  evaluation  of  the 
IADS.  Through  our  Block  0  analysis  efforts  we  have  solicited  Service  input  for 
identifying  the  required  M&S,  HWIL,  and  OITL  analytic  tools  to  conduct  our  analysis. 

We  recognize  that  each  tool  brings  with  it  selected  capabilities  and  limitations  at  each 
level  of  evaluating  SoS  performance.  We  are  using  a  federation  approach,  linking  an 
optimized  mix  of  tools,  to  map  system  performance  to  warfighting  benefit.  The  following 
paragraphs  address  the  capabilities  of  the  various  tools  under  consideration. 

2.2.2.1.  Modeling  and  Simulation 

Numerous  constructive  simulations  (tools  that  run  faster  or  slower  than  real  time 
without  human  interaction)  exist  that  have  varying  capabilities  to  analyze  either  the 
performance  of  SIAP-related  systems  or  the  operational  effectiveness  of  missions 
relying  on  SIAP  information.  These  simulations  exist  at  several  levels  of  scope, 
including  campaign  level,  mission  level  (otherwise  referred  to  as  scenario  level  or 
theater  level),  engagement  level  (otherwise  referred  to  as  vignette  level)  and 
system/subsystem  level.  Such  environments  include  purely  digital  simulations  such  as 
the  Air  Defense  Simulation  Tool  used  at  Modeling,  Analysis  and  Simulation  Center  at 
Electronic  Systems  Command,  Hanscom  MA,  the  widely  used  Extended  Air  Defense 
Simulation  environment,  and  service  specific  platform  models  and  engineering  test¬ 
beds. 


We  are  working  with  Service  Subject  Matter  Experts  (SMEs)  to  identify  the 
appropriate  M&S  tools  to  use  in  our  constructive  simulation  environment.  To  credibly 
use  these  tools,  the  models  must  be  appropriately  validated  and  the  platform/fighting 
unit  representations  must  be  endorsed  by  the  Services.  Services  agreed  to  support  the 
verification  and  validation  of  SIAP-related  M&S  tools  in  the  SIAP  Charter.  To  date,  not 
much  progress  has  been  made  to  validate  many  of  the  tools  used  to  characterize  IADS 
performance. 
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Recommendation:  DoD  lead  an  extensive  effort  to 
validate  the  appropriate  M&S  toois  to  support  FoS  for 
SiAP-related  analysis. _ 


2.2.2.2.  Hardware-in-the-Loop 

The  HWIL  environment  moves  testing  a  step  closer  to  evaluating  the 
performance  of  operational  systems.  HWIL  events  can  be  used  to  address 
interoperability  issues  and  unforeseen  equipment  and  computer  program  conflicts.  In 
the  case  of  the  SIAP,  HWIL  testing  is  performed  with  either  baseline  or  engineering  load 
software  reflecting  the  proposed  changes.  HWIL  testing  is  generally  limited  to  a  small 
number  of  systems  and  configurations.  These  limitations  inject  uncertainty  with  respect 
to  how  well  the  tests  actually  represent  the  real  world.  These  HWIL  environments 
include:  the  Joint  Distributed  Engineering  Plant  (JDEP),  Theater  Missile  Defense 
Simulation  Environment  (TMDSE)  and  the  aviation  extension  of  JDEP,  Distributed 
Network  (DNet).  These  tools  are  limited  by  simulation/stimulation  inputs.  No  organized 
process  exists  to  validate  sensor,  environmental,  and  scenario  generation  tools  for  Joint 
use. 

2.2.2.3.  Operator-in-the-Loop 

OITL  events  are  cost-effective  ways  to  evaluate  integrated  system  environments 
with  respect  to  the  man-machine  interface.  However,  as  with  HWIL,  virtual  OITL  events 
generally  are  limited  in  their  capability  to  fully  replicate  family  of  systems  functionality. 

As  previously  noted,  no  standardized,  jointly  endorsed  process  currently  exsists. 

Testers  should  consider  these  limitations  when  evaluating  the  utility  of  OITL  events 
alone.  Like  the  HWIL  environment,  no  organized  process  exists  to  validated  sensor 
environmental,  and  scenario  inputs  to  these  tools. 


Recommendation:  Support  an  orchestrated 
standardized  process  for  validating  SIM/STIM  sensor 
and  environmental  inputs  to  HWIL  and  OITL  tools. 


2.2.2.4,  Empirical  Analysis 

Live  exercises  can  be  used  to  baseline  real  system  performance  and  validate 
M&S  results.  Future  events  support  analysis  of  performance  deltas  after  changes  to  the 
systems  are  implemented.  Each  system  can  record  data  for  post-event  forensic 
analysis.  The  amount  and  type  of  data  can  vary  from  system  to  system  as  well  as  event 
to  event. 

Additional  factors  influence  the  amount  and  quality  of  the  data  available  (e.g. 
equipment  failures,  weather,  number  and  type  of  platforms  participating  in  the  events.) 
However,  empirical  analysis  can  provide  representative  information  from  real  system 
hardware,  operated  by  real  warfighters,  in  realistic  engagements  and  therefore 
represents  very  credible  exhibitions  of  SIAP  performance. 

So-called  data-driven  modeling  tools  such  as  those  used  by  the  Center  for  Naval 
Analyses'  Operational  Data  Driven  for  Correlation  Algorithm  Performance  Evaluation 
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(ODDSCAPE)  and  Naval  Surface  Warfare  Center,  Corona  Division’s  Performance 
Evaluation  Tool  (PET)  support  replay  of  live  exercise  data. 

2-2.2.5.  Prior  Studies 

Lessons  learned  from  previous  SIAP-related  studies  support  ongoing  analysis. 
While  each  study  typically  uses  differing  methodologies,  metrics,  and  objectives,  results 
from  prior  efforts  when  reviewed  in  the  context  support  ongoing  SIAP-related  efforts.  It 
is  our  objective  to  standardize  the  methodologies,  metrics  and  objectives  to  support  the 
capability  to  compare  and  contrast  results.  In  addition,  these  studies  become  sources 
for  lessons  learned.  The  formal  Service  review  of  the  1999  JTAMDO  Joint  Mission  Area 
Assessment  (JMAA)  SIAP  Technology,  Architecture  and  Roadmap  (TAR)  study 
characterized  this  effort  as  a  viable  stepping-stone  for  further  SIAP  analysis.  The  JMAA 
TAR  study  is  a  foundational  tool  for  SIAP  analysis  efforts. 

We  are  using  the  combination  of  M&S,  HWIL,  OITL,  empirical  analysis  and  prior 
studies  to  support  a  comprehensive  analysis  effort  for  evaluating  IADS  performance, 
predicting  capability  and  prescribing  improvement.  We  have  documented  this  process 
in  the  SIAP  Integrated  Assessment  Plan  (lAP).  The  lAP  is  addressed  in  more  detail 
later  in  this  report  and  can  be  input  into  our  lessons  learned  database. 


2.2.3,  Metrics 

A  critical  part  of  system  engineering  the  SIAP  is  identifying  the  degree  to  which 
we  are  meeting  JROC-validated  warfighting  requirements.  The  definition  of  SIAP  lends 
itself  to  quantifiable  warfighting  Measures  of  Effectiveness  (MOEs),  mission  level 
attributes,  and  system  level  Measures  of  Performance  (MOPs).  Once  these  values  have 
been  defined,  we  can  proceed  with  developing  realistic  operational  tests  to  evaluate 
compliance.  As  noted  earlier  operational  requirements  for  the  SIAP  are  found  in  the 
TAMD  and  CID  CRD.  These  operational  requirements  must  be  translated  (in  a 
traceable  way)  into  lower-level  technical  requirements  that  support  a  disciplined  system 
engineering  process,  and  to  objectively  assess  progress  in  achieving  the  required  SIAP 
capability.  However,  as  indicated,  one  of  the  SIAP  SE’s  Jobs  is  to  help  evolve  the 
definition  of  SIAP.  This  will  be  natural  fallout  of  the  systems  engineering  efforts  that  will 
be  undertaken  to  create  a  SIAP  that  most  efficiently  and  effectively  meets  warfighting 
requirements. 

Quantifiable  and  testable  MOEs,  attributes,  and  MOPs,  are  the  linchpin  to  the 
SIAP  system  engineering  efforts.  Quantifiable  MOEs  and  MOPs  must  support  various 
analysis  methods  including  sensitivity  analyses  to  support  technical  trade-offs,  modeling 
and  simulation,  critical  experiments,  land-based  test  and  evaluation,  JDEP  and  JNTF 
wargaming,  interoperability  certification  (such  as  that  provided  by  Joint  Interoperability 
Test  Command  (JITC)),  and  evaluation  in  an  operational  context  (such  as  JCIET)  of 
SIAP-related  changes  and  other  warfighting  capability  improvements.  We  have  worked 
very  closely  with  the  Services  and  Joint  organizations  to  develop  a  quantifiable  set  of 
SIAP-related  measures.  Such  measures  provide  answers  to  three  fundamental 
questions: 


28 


•  What  do  we  have  today?  (Evaluative  measures) 

•  What  is  required?  (Predictive  measures) 

•  How  do  we  get  what  we  need?  (Prescriptive  measures) 

Metrics  are  used  to  objectively  evaluate  candidate  approaches  to  meet  JROC- 
validated  Capstone  requirements.  Additionally,  they  allow  us  to  understand  how  we  are 
progressing  toward  the  end-state. 

Quantifying  answers  to  these  questions  provide  an  analysis  roadmap  for  system 
improvement.  Ultimately  these  types  of  measurements  must  be  evaluated  at  various 
levels  of  aggregation  i.e.,  measurements  at  the  system/platform  level,  mission/ 
effectiveness,  theater,  and  force  level.  These  levels  determine  a  hierarchy  of 
quantifiable  characteristics  as  shown  in  Figure  4.  The  roll-up  of  quantifiable  measures 
from  MOPs  at  the  system  level  to  MOEs  at  the  warfighting  level  provides  the  capability 
to  determine  how  systemic  problems  and  improvements  affect  warfighting  capability. 

To  build  a  common  lexicon,  and  make  progress  toward  achieving  the  SIAP,  it  is 
critical  that  the  processes  and  products  that  result  from  the  various  measures  and 
attributes  efforts  converge  to  a  standardized  approved  set.  At  a  minimum,  a  standard 
set  of  definitions  and  derivations  of  SIAP  attributes  must  be  established  and  universally 
used  across  services  and  joint  organizations.  These  attributes  provide  a  common 
reference  to  measure  a  SIAP.  In  addition,  the  appropriate  MOEs  and  MOPs  are  being 
identified  for  use  by  testers,  analyzers  and  evaluators  such  that  common  criteria  will 


Figure  4.  MOE/MOP  Mapping 


Technical  specifications  as  translated  into  MOPs  can  quantify  system 
functionality.  MOPs  defining  system  level  measures  are  fundamental  characterizations 
of  how  IADS  equipment  and  computer  programs  operate.  Table  3  lists  representative 
MOPs. 
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_ Table  3:  Representative  MOPs _ 

•  Time  difference  between  system  internal  time  at  central  track 
stores  and  JTIDS  terminal 

•  Latency  of  messages  due  to  buffering,  prioritization,  staleness, 
and  time  slot  allocation 

•  Translational  and  rotational  error  quantities 

•  Percent  of  time  units  correctly  report  track  quality  with  respect  to 
MIL-STD-6016A 


MOEs  define  IADS  performance  in  terms  that  matter  most  to  the  warfighter. 
Table  4  lists  several  MOEs. 


_ _ Table  4:  Representative  MOEs _ 

•  Distance  target  penetrated  blue  air  space 

•  Number  of  blue  losses  to  red  due  to  air  picture  or  CID 

•  Number  of  blue  losses  to  blue  due  to  blue  being  misidentifled  as 
red 

•  Number  of  blue  defended  assets  lost;  blue  casualties 


Quantifiable  SIAP  attributes  relate  MOPs  to  MOEs.  Through  a  collaborative 
working  group  composed  of  joint  C/S/A  representatives,  we  have  derived  and  defined 
eight  key  attributes,  which  characterize  SIAP  performance.  These  attributes  flow 
directly  from  KPPs  defined  by  the  TAMD  and  CID  CRDs.  Figure  5  lists  the  set  of  SIAP 
attributes. 

The  SIAP  attributes  are  easily  measured  surrogates  for  the  measures  of 
effectiveness. 
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Completeness:  The  air  picture  is  complete  when  all  objects  are 
detected,  tracked  and  reported. 

Clarity:  The  air  picture  is  clear  when  it  does  not  include  ambiguous 
or  spurious  tracks. 

Continuity:  The  air  picture  is  continuous  when  the  tracks  are  long 
lived  and  stable. 

Kinematic  Accuracy:  The  air  picture  is  kinematically  accurate  when 
the  position  and  velocity  of  a  track  agrees  with  the  position  and  velocity 
of  the  associated  target. 

ID  Completeness:  The  ID  is  complete  when  all  tracked  objects  are 
labeled  in  a  state  other  than  “unknown”. 

ID  Accuracy:  The  ID  is  accurate  when  all  tracked  objects  are 
labeled  correctly. 

ID  Clarity:  The  ID  is  ambiguous  when  a  tracked  objects  has  two  or 
more  conflicting  ID  states. 

Commonality:  The  air  picture  is  common  when  the  tracks  held  by 

each  participant  have  the  same  track  number,  position,  and  ID. _ 

Figure  5.  SIAP  Attributes 

Recommendation:  Institutionalize  SIAP  metrics 
as  the  assessment  measures  of  choice  for 
characterizing  SIAP  performance. 


2.2.4.  Coordinated  Analysis  Process 

We  are  leveraging  existing  test  and  evaluation  assets  to  provide  credible,  and 
complete  system  engineering  analysis  to  support  recommendations  to  the  JROC. 
Evaluation  of  mission  area  performance  supports  iterative  utilization  of  the  previously 
described  analysis  venues  described.  DoD  5000.2R  calls  for  a  portfolio  management 
process  whereby  "investments  are  grouped  by  mission  related  or  business  process  to 
establish  a  portfolio.  Trade-offs  among  investments  are  made  to  maximize  benefit  to 
the  mission,  and  benefits  are  measured  and  evaluated  in  the  context  of  the  overall 
strategy  for  the  mission."  Figure  6  depicts  an  analysis  process,  which  starts  from  an 
operational  architecture  and  joint  requirements  and  iterates  the  evolution  of  capability 
through  various  system-specific  and  integrated  environments.  Each  venue  is 
supportive.  By  linking  various  venues,  an  end-to-end  analysis  effort  will  support 
forensic  investigation  of  SoS  integration  deficiencies,  prescribe  improvements  to 
systems,  and  predict  warfighting  performance  based  on  those  improvements.  At  each 
step,  results  are  evaluated  in  the  context  of  the  IADS  portfolio. 

One  of  the  key  elements  in  the  analysis  process  is  the  SIAP  lAP  designed  to 
support  the  IADS  portfolio  at  each  level  and  is  detailed  in  section  2.2.5.  The  end  state, 
however,  is  to  ensure  that  the  tools  support  development  of  quality  and  reliably 
integrated  systems,  which  perform  flawlessly  during  open-air  exercises. 
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Figure  6.  Analysis  Process 


Live  events  generally  support  two  purposes;  1)  training,  and  2)  verification  and 
validation.  Operators  and  engineers  compete  for  hardware  and  time  during  exercises. 
This  competition  limits  the  effectiveness  of  both  endeavors.  We  desire  an  end-state 
where  live  event  evaluation  proves  capability  rather  than  deficiency.  Our  goal  is  for 
leadership  to  be  surprised  when  interoperability  fails  during  joint  exercises,  rather  than 
expect  deficiencies.  In  addition,  by  increasing  the  capability  to  perform  credible  land- 
based  integrated  system  performance  evaluation,  a  large  measure  of  quality  assurance 
testing  is  moved  out  of  the  live  environment  back  into  the  shore-based  test  facilities. 

Our  efforts  to  build  an  IADS  portfolio  must  be  supported  by  the  dedicated  lOT&E 
required  by  law.  Our  efforts  must  be  integrated  and  endorsed  by  DOT&E  to  support 
mission  capability  assessments. 

We  have  two  primary  ways  of  testing  at  the  IADS  level.  The  first  method  uses  the 
extensive  test  networks,  in  place  today,  to  interconnect  the  systems  that  comprise  an 
IADS  and  to  challenge  this  configuration  with  threat-representative  scenarios.  This 
testing  shows  discontinuities  in  the  interface  between  individual  systems  (e.g. 
implementation  of  the  Tactical  Data  Link  Standards).  These  discontinuities,  in  turn,  are 
resolved  by  the  individual  implementing  systems.  Certification  of  specification 
compliance  by  each  of  the  individual  systems  is  necessary  (but  not  sufficient)  to  meet 
our  IADS  requirements. 


A  joint  analysis  team  such  as  the  JIADS  IWG  is  a  means  by  which  we  can 
continue  to  encourage  collaborative  IADS  assessments.  The  most  important  products  of 
the  JIADS  IWG  is  the  increased  communication  in  the  acquisition  community,  and  the 
training  our  engineers  obtain  in  developing  systems  that  will  support  joint  operations. 
Assessing  capability  and  performance  byway  of  either  of  the  above  methods  is 
supported  by  three  essential  elements;  people,  products  and  processes. 
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Recommendation:  DOT&E  to  support  an  end-to- 
end  SIAP  analysis  process,  led  by  the  SIAP  SE, 
which  leverages  tools  at  all  levels  of  system  test  and 
evaluation.  _ 


2.2.5.  Integrated  Assessment  Process 

As  noted  above,  Department  of  Defense  invests  significant  resources  each  year 
to  develop  and  use  Joint  and  Service-specific  T&E  tools.  However,  the  various 
resources  are  rarely  used  collaboratively.  Unique  exercise  objectives,  requirements, 
planning,  evaluation  criteria,  metrics,  and  analysis  limit  comparison  of  results  from  one 
venue  with  those  of  another. 

We  have  integrated  the  above  standardizing  products  through  an  Integrated 
Assessment  Plan  (lAP).  The  lAP  specifies:  M&S,  HWIL,  OITL,  and  open  air  tools  for 
performing  analysis;  analysis  methods;  supporting  organizations;  required  CRS 
engineering  vignettes;  network  designs;  and  reporting  requirements.  The  lAP  also 
addresses  the  federation  and  integration  of  tools,  which  supports  identification  of 
underlying  system  deficiencies  rolled-up  to  warfighting  effects.  The  federation  of  tools 
approach  has  been  piloted  through  a  SIAP  Metrics  Proof  of  Process  (MPoP)  effort.  The 
MPoP  maps  system  functional  deficiencies  to  warfighting  effects  i.e.,  weapons 
expenditure,  and  fratricide  for  a  specific  engineering  vignette.  This  effort  mapped 
sensor  registration,  navigation  positional,  and  track  quality  reporting  errors  to  SIAP 
attributes  of  Clarity  and  Kinematic  Accuracy  and  respective  warfighting  MOEs.  The 
MPoP  provides  an  example  of  the  fundamental  aspects  of  the  lAP  process.  Figure  7 
depicts  the  MPoP  pilot  effort. 
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Figure  7.  SIAP  Metrics  Proof  of  Process:  Data  Registration  Requirement  Mapping 

The  SIAP  SE  Task  Force  will  leverage  existing  Test  and  Evaluation  (T&E) 
capabilities  to  provide  credible,  and  complete  system  engineering  analysis  to  support 
recommendations  to  the  JROC.  As  noted  above,  the  DoD  invests  significant  resources 
each  year  to  develop  and  use  Joint  and  Service-specific  M&S,  HWIL,  OITL  and  live 
evaluations  for  the  purpose  of  assessing  IADS  performance.  However,  the  various 
resources  are  rarely  used  collaboratively.  Unique  exercise  objectives,  requirements, 
planning,  evaluation  criteria,  metrics,  and  analysis  limit  comparison  of  results  from  one 
venue  with  those  of  another. 

2.2.6.  Critical  Experiments 


Objective  and  repeatable  analysis  is  supported  by  well-planned  critical 
experiments.  Critical  experiments  document  objectives,  rationale,  purpose,  expected 
outcome,  metrics,  requisite  conditions,  and  standardized  methodologies  for  assessing 
key  SIAP-related  issues.  We  have  defined  an  initial  list  of  nine  critical  experiments  for 
evaluation  in  various  T&E  venues.  Figure  8  provides  the  initial  list  of  related  SIAP 
critical  experiments.  Results  from  these  critical  experiments  will  be  documented  and 
catalogued  for  comparison  with  M&S/HWIL/OITL  analysis  and  other  open-air  exercises 
to  support  engineering  decision-making.  The  critical  experirhents  allow  us  to  develop 
and  challenge  specific  SIAP-related  hypotheses  and  to  use  what  we  learn  to  make 
improvements.  As  critical  experiments  are  completed,  and  results  are  digested,  the  list 
will  be  adjusted. 
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•  Time  Synchronization 

•  Sensor  tracking/reporting  accuracy 

•  Commonality 

•  Data  registration 

•  Automatic  Local-to-Remote  Track  Correlation/Decorrelation 

•  Identification  processing 

•  PPLI  accuracy 

•  Formation  tracking  and  assessment 

•  Model  validation _ _ 

Figure  8.  Initial  SIAP  Critical  Experiments 

These  critical  experiments  are  directly  linked  to  the  Block  improvements  and  to 
the  SIAP  Integrated  Architecture. 

During  Roving  Sands  FY01  (RS01 )  the  SAT  supported  by  Service  Subject  Matter 
Experts  used  modified  critical  experiment  to  support  evaluation  of  AN/TPS-59  and 
Patriot  sensor  registration  capabilities.  These  SIAP  critical  experiments  will  be  used 
during  JCIET  02. 

Recommendation:  Endorse  SIAP  critical  experiments 
as  primary  objectives  for  SIAP-related  analysis  across 
venues.  _ _ 


2.3.  CHARACTERIZATION  OF  THE  EXISTING  CONDITION 

The  previous  sections  address  infrastructual  improvements  to  institutionalize 
discipline  in  our  analysis  efforts.  These  improvements  directly  support  and  are  directly 
supported  by  other  SIAP  SE  products  and  processes.  Our  LLDB  provides  repository  for 
storing  observations  and  warfighting  shortfalls  identified  through  our  analysis  efforts. 

The  proposed  concept  for  this  database  sees  an  electronic  linkage  to  already 
established  lessons  learned  database  efforts  in  the  Services  and  Joint  agencies.  Data 
in  repositories  such  as  the  AFKKLB,  Navy  LLDB,  and  JFCOM  JCLL  must  be  culled  for 
SIAP-related  data,  then  linked  to  a  centralized  SIAP  repository,  quite  possibly 
associated  with  one  of  these  existing  tools.  The  SIAP-repository  then  provides  an 
engineering  warehouse  for  SAT  forensic  and  prescriptive  analysis  and  supports  the 
development  of  IADS  capabilities  and  limitations  document. 

In  addition,  the  SIAP  SVs  and  TVs  of  the  TAMD  integrated  architecture  become 
the  technical  context  for  defining  SIAP  functionality  to  support  mapping  system 
performance  to  warfighting  capability.  We  cannot  define  the  beginning  and  end-states 
evaluative  and  predictive  efforts  without  defining  this  architecture.  Upon,  completion  the 
integrated  architecture  becomes  a  repository  for  all  our  engineering  efforts. 

The  development  of  our  analytic  infrastructure  also  directly  supports  our  Block 
improvement  recommendation  process.  Each  of  the  identified  tools,  processes  and 
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associated  teams  are  required  to  support  the  disciplined  approach  we  were  chartered  to 
build. 


The  services  continue  generate  substantial  evidence  of  warfighting  shortfalls 
within  the  IADS.  Post-action  reports  from  military  operations,  training  exercises,  and 
joint  evaluations  such  as  those  conducted  by  the  All  Service  Combat  Identification 
Evaluation  Team  (ASCIET),  identify  specific  issues.  We  have  developed  a  process  for 
collecting  and  consolidating  these  SIAP-related  issues. 

In  accordance  with  the  SIAP  SE  Charter,  CINCUSJFCOM  will  sponsor  the 
resolution  of  TTP  issues  on  behalf  of  the  Joint  warfighter  to  the  appropriate  operational 
organization(s). 

We  expect  the  Service  system  program  mangers  to  resolve  computer  program 
deficiencies  applicable  to  their  systems.  CINCUSJFCOM  can  have  a  significant 
influence  in  the  prioritization,  scheduling,  and  ultimate  implementation  of  the  fixes  to 
these  problems  by  working  with  the  Services  to  ensure  appropriate  direction  and 
resources  are  in  place  for  the  program  mangers  to  take  remedial  action. 

The  SIAP  SE  has  collaborated  with  the  respective  Services  to  analyze  structural 
and  unresolved  issues  as  part  of  the  SIAP  SE’s  lessons  learned  efforts  Service  and 
MDA  “top  ten”  lists  have  been  generated.  The  "top  ten"  lists  were  categorized  as 
described  above.  Other  amplifying  information  has  been  included  such  as:  observation 
date,  time,  event  origin,  systems  involved,  recorded  data  information,  etc. 

We  are  developing  a  lessons  learned  repository,  leveraging  existing  service/joint 
capabilities  such  as  the  Joint  Automated  Lessons  Learned  Tool.  We  believe  an 
automated  tool  can  contribute  significantly  to  collecting,  tracking,  and  documenting  the 
resolution  of  technical  interoperability  shortfalls. 


Recommendation:  Support  the  development  of 
an  automated  Lessons  Learned  Database  to  provide 
a  repository  for  collecting  and  consolidated  joint 
SIAP-related  lessons  learned. 


2.4.  INCREMENTAL  CAPABILITY  IMPROVEMENT 

The  SIAP  SE  TF  plan  focuses  first  on  recommending  specific  changes  in  the 
systems  that  support  the  "JDN”,  while  ensuring  the  fixes  are  on  a  path  to  an  effective 
SIAP  capability.  Incremental  SIAP  block  upgrades  will  evolve  from  near-term  “JDN” 
fixes  that  improve  current  capability  and  build  to  fielding  a  SIAP  capability  that  meets 
the  requirements  defined  by  the  TAMD  and  CID  CRDs.  Implementation  of  materiel  JDN 
fixes  is  expected  to  require  modification  to  affected  host-system  computer  programs 
and  equipment.  Computer  programs  and  equipment  must  be  modified  to  implement  the 
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fixes,  and  then  the  systems  must  be  tested  and  certified  following  implementation  of  any 
changes.  This  process  becomes  quite  complex  given  that  many  of  the  systems  have 
existing  upgrade/update  plans  and  schedules,  and  they  may  be  impacted  by  constraints 
such  as  shipbuilding  schedules  or  Operational  Flight  Program  (OFP)  upgrades. 

The  most  cost-effective  approach  to  implementing  near-term  “JDN”  fixes  is  to 
consolidate  them  into  logical  block  upgrades  to  minimize  the  number  of  times  that  host 
computer  programs  must  be  modified  and  tested.  It  is  important  to  understand  the 
definition  of  “JDN”.  From  the  TAMD  CRD,  "the  backbone  of  the  JDN  is  Link  16 
transmitted  via  JTIDS  and  MIDS  terminals.  The  JDN  is  the  collection  of  near-real-time 
communications  and  information  systems  used  primarily  at  the  coordination  and 
execution  levels.”  Therefore,  the  SIAP  SE  Task  Force  is  focusing  on  specific  tactical 
data  link  fixes,  with  an  emphasis  on  Link  16. 

The  SIAP  SE  Task  Force  has  established  milestones  to  provide  an  initial 
recommendation  for  a  Block  0  upgrade  by  December  2001,  with  Block  1  to  follow  12 
months  later,  and  future  Block  upgrades  to  follow  on  a  two  year  periodic  to  coincide  with 
the  budget  cycle.  To  identify  the  root  cause  problems  that  would  be  addressed  in  these 
blocks,  the  Joint  IADS  (JIADS)  Interoperability  Working  Group  (IWG)  analyzed  ASCIET 
99  and  ASCIET  00  data.  Over  30  items  were  identified  as  significant  issues  that 
needed  to  be  addressed.  Four  of  the  items  were  selected  and  endorsed  by  the  JROC 
as  the  Initial  demonstration  of  the  SIAP  SE  process,  and  these  form  the  basis  of  the 
Block  0  upgrade. 

The  four  Block  0  items  were  selected  due  to  their  impact  on  the  “JDN”,  their 
applicability  across  all  four  services,  and  the  broad  set  of  SIAP  system  engineering 
processes  that  will  be  developed  and  used  to  address  them.  The  Block  0  items  are: 

a.  Correlation/De-correlation  (ICP  TM98-035  Ch  10).  This  ICP  standardizes  the 
correlation/de-correlation  processing  for  all  systems  participating  on  Link  16  by 
prescribing  the  method  by  which  the  correlation  “window”  will  be  computed  as  well  as 
providing  details  on  the  use  of  kinematic,  identification  (ID),  and  Identification  Friend  or 
For  (IFF)/Selective  Identification  Feature  (SIF)  data  in  the  correlation/de-correlation 
process.  This  ICP  was  selected  because  it  has  great  promise  to  reduce  the  incidence 
of  dual  tracks  and  because  it  was  already  approved  by  the  Services  for  Allied 
coordination  through  the  JINTACCS  process.  This  ICP  also  allowed  us  to  better 
understand  the  present  operation  of  the  JINTACCS  process  and  to  examine  how  best  to 
link  the  interface  change  process  to  the  requirements  generation  process  and  how  to  tie 
both  of  these  to  the  SIAP  integrated  Architecture. 

b.  Identification  (ID)  taxonomy  and  symbology  (ICP  TJOO-002).  This  ICP  defines 
minimum  implementation  requirements  for  systems  participating  on  Link  16.  The  ID 
section  of  the  minimum  implementation  requirements  stipulates  that  all  systems 
operating  on  Link  16  will  implement  all  seven  ID  values  (Pending,  Unknown,  Suspect, 
Assumed  Friend,  Neutral,  Friend,  Hostile)  contained  within  MIL-STD-6016A.  Currently, 
some  systems  have  only  implemented  a  subset  of  these  seven  values.  This  may  lead 
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to  operator  confusion  and  the  loss  of  previously  derived  data  following  a  reporting 
responsibility  shift  to  these  systems  that  have  not  implemented  all  seven  values.  The 
TADIL  J  Minimum  Implementation  (Taxonomy)  ICP  was  selected  because  it  was  the 
one  issue  that  CINCUSJFCOM  wanted  resolved  due  to  the  impact  of  symbology 
mismatch  on  the  operational  forces.  This  change  also  allowed  us  to  understand  the 
connection  between  the  symbology  used  on  displays,  underlying  information  taxonomy, 
and  adequacy  of  the  present  interface  standards  (e.g.,  MIL-STD-6016A)  for  use  as  a 
contractual  requirements  document. 

c.  ID  conflict  resolution  matrix  (ICP  TM94-005  Ch  10).  This  ICP  establishes  the 
standardized  way  to  process  the  resolution  of  ID  differences  between  units.  The  ICP 
stipulates  under  which  conditions  a  track’s  ID,  that  is  received  from  another  unit  and  is 
different  than  the  locally  held  ID,  will  be  automatically  accepted,  automatically  rejected, 
or  subject  to  operator  review.  It  also  provides  the  rules  for  the  transmission  and 
processing  of  ID  Difference  report  messages.  This  ICP  was  selected  because  it  has 
been  approved  for  implementation  and  because  it,  too,  has  great  promise  to  reduce 
operator  workload  and  distraction.  It  was  also  selected  because  we  wanted  to 
understand  the  coupling  of  algorithms  such  as  this  to  the  TAMD  and  CMD  CRD 
requirements. 

d.  Formation  Tracking/Correlation.  This  is  not  an  ICP,  but  a  problem  statement. 
The  problem  arises  from  a  difference  in  how  services  handle  “formation”  tracks,  one 
track  that  is  used  to  represent  more  than  one  object,  on  Link  16.  A  unit,  usually  an 
airborne  surveillance  unit,  transmits  a  formation  track  as  a  workaround  for  underlying 
system  limitations.  When  another  unit,  such  as  a  shooter  with  a  higher  fidelity  sensor 
and  tracker,  receives  the  formation  track  and  correlates  it  to  one  of  the  local  tracks  in 
the  formation,  that  unit  is  left  with  unidentified  tracks  for  the  other  objects  in  the 
formation.  The  formation  assessment  methods  currently  used  for  identifying  the  other 
objects  are  inconsistent.  Also,  the  Correlation/Decorrelation  ICP  includes  a  restriction 
preventing  the  correlation  of  a  formation  track  with  a  local  track;  this  will  increase  the 
number  of  unidentified  tracks  at  the  shooter.  In  addition,  USJFCOM  stated  that 
formation  tracking  is  inconsistent  with  the  TAMD  CRD  requirement  for  one  track/object. 
SIAP  SE  TF  is  leading  a  joint  team  that  will  identify  the  underlying  system  limitations  for 
which  formation  tracking  is  used  as  workaround  and  the  limitations  of  formation  tracking 
and  assessment.  The  team  will  recommend  improvements  to  the  limitations  and 
perform  analysis  to  refine  the  recommendations.  The  formation  tracking  issue  was 
introduced  by  the  U.S.  Army  as  a  challenge  to  the  Automatic  Local-to-Remote  Track 
Correlation/  Decorrelation  ICP.  The  Correlation  ICP  specifically  prohibited  correlation  of 
tracks  with  differing  strength  values  indicating  the  sensor/operator  belief  that  two  aircraft 
are  associated  with  a  single-track  report.  The  Army  challenge  to  the  Appeal  Panel  was 
denied.  However,  the  Army  and  the  USAF  were  directed  to  form  a  working  group  to 
design  rules  for  the  association  of  formation  tracks  and  the  subsequent  transfer  of 
identification  and  other  critical  information.  This  group  did  not  operate  as  a  formal  part 
of  the  JINTACCS  process,  and  is  now  functioning  as  part  of  the  SIAP  Effort. 
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The  four  Block  0  items  were  selected  due  to  their  impact  on  the  JDN,  their 
applicability  across  all  four  Services,  and  the  fact  that  three  of  the  four  issues  were 
already  approved  by  the  JINTACCS  process  (2  for  implementation  and  1  for  allied 
coordination).  By  picking  issues  that  have  been  previously  approved  by  the 
JINTACCS  process,  we  are  able  to  assess  the  JINTACCS  process  effectiveness  in 
meeting  JROC-validated  warfighting  requirements  and  identify  process 
improvements  to  better  support  warfighting  needs.  The  Block  0  Items  are  listed  in 
Table  5  and  more  details  regarding  their  selection  are  presented  below. 

_ _ _ Table  5:  Block  0  Items _ 

1.  Correlation/De-correlation  (ICP  TM98-035  Ch  10) 

2.  Identification  (ID)  Taxonomy  and  Symbology  (ICP  TJOO- 
002) 

3.  ID  Conflict  Resolution  Matrix  (ICP  TM94-005  Ch  10) 

4.  Formation  Tracking  /  Correlation _ _ 

The  Services  were  asked  to  nominate  systems  to  implement  these  four  JDN 
fixes.  At  first  12  “core”  systems  were  selected  from  92  systems  utilizing  Link  16  in 
large  part  due  to  their  plans  to  participate  in  JCIET  2002.  This  exercise  would 
provide  an  opportunity  for  the  SIAP  SE  TF  and  the  joint  community  to  assess  the 
impact  of  the  fixes  in  an  operational  environment.  Additionally  as  part  of  the  Block  0 
initiative,  the  Block  0  team  and  Service  representatives  recommended  other  systems 
consider  implementing  the  Block  0  fixes  to  improve  joint  warfighting  capability.  Of  92 
Link  16  systems,  the  Block  0  team  used  a  down  select  process  to  define  a 
manageable  set  of  systems  and  configurations  to  perform  an  optimized  acquisition 
analysis  (see  table  6).  These  systems  meet  several  common  criteria; 

-  Support  air  and/or  cruise  missile  defense. 

-  Established  IOC  before  or  during  FY06  through  the  POM  04  FYDP. 

-  Produce  SIAP  tracks. 
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Table  6:  Block  0  Systems 


Army 

PATRIOT  ICC 
FAADC2 

AMDPCS 

PATRIOT  BCP 
RAH-66 

ADAM  Cell 

USMC 

TAOM 

Navy 

ACDS  BIk  0 

ACDS  BIk  1 

AEGISB/L 

5.3/3A.0X 

AEGIS  B/L6.1 
AEGIS  B/L6.3 
AEGIS  B/L 

7PH1 

SSDS  MK  2 

E-2C  Group  II 

E-2C  Group  IIN, 

MCU,  &  CEC 
FA/18C/D&E/F 

USAF 

E-3  (AWACS) 

F-16  BIk  40 

F-16  BIk  50 

B-2 

F-22 

TACP-M 

F-15  Suite 

5M/  5E 

MCE,  V.111 

RIVET  JOINT 

Note:  Bold  indicates  Block  0  “Core”  Systems 

The  Block  0  team  delivered  a  decision  support  binder  (DSB)  in  December 
2001 .  The  DSB  represents  the  centerpiece  of  Task  Force  activity  and  the  focal  point 
for  SIAP  products.  The  Task  Force  will  develop  a  plan  for  each  block  to  identify  the 
specific  changes  to  be  implemented  in  specific  systems  to  achieve  specific 
improvements  to  the  JTAMD  FoS  SIAP  capability.  Block  Improvement  Plans  will 
include: 


-  Engineering  specifications-ICPs,  and  other  technical  specifications  that 
must  be  implemented  in  each  system  to  achieve  the  desired  capability, 

-  Supporting  rationale-the  test  results  and  analysis  that  project  the  warfighter 
benefits  for  fielding  the  engineered  fixes, 

-  Acquisition  estimates-total  cost/system  costs  to  implement  specified 
upgrades  as  well  as  schedule  recommendations  for  synchronizing  block 
upgrades  with  ongoing  programs  and  aligning  key  insertion  points  for  SIAP 
functionality.  The  Task  Force  will  also  recommend  which  systems  should 
not  be  upgraded  based  on  cost-benefit  analyses. 

We  envision  that  the  SIAP  Block  Improvement  Plans  will  be  the  key  decision 
document  for  JROC  approval  to  proceed  with  implementation  of  each  SIAP  block 
upgrade.  The  Block  0  effort  was  de-scoped  as  a  result  of  budget  limitations  driven 
by  the  delayed  Congressional  approval  of  the  FY01  Above  Threshold 
Reprogramming  action.  However,  significant  effort  will  be  completed  to  provide: 

-  Current  Link-16  architecture  incorporating  the  12  Block  0  core  systems, 

-  Analysis  of  the  effect  of  incorporating  the  Block  0  changes  into 
representative  systems  up  to  the  campaign  level,  and  an 
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-  Acquisition  assessment  of  the  recommended  systems  including  cost 
estimates  for  incorporating  the  Block  0  changes  and  a  roadmap  view  of 
when  the  changes  will  be  incorporated  into  the  individual  weapon  system. 

The  acquisition  assessment  will  provide  a  JDN  "system  of  systems"  view  of  ICP 
implementation  across  the  targeted  systems  and  facilitate  any  recommendations 
required.  The  cost  information  will  deliver  budget  estimate  data  the  Services  can  use  to 
build  the  POM  submissions  needed  to  fund  Block  0  implementation  in  both  the  core  and 
recommended  systems. 

Overall,  SIAP  budget  limitations  severely  impacted  the  quality  of  budget  and 
schedule  data  the  Block  0  team  was  able  to  acquire.  Many  services  were  unable  or 
unwilling  to  provide  data  above  rough  estimates  due  to  the  cost  to  acquire  cost 
estimates  from  the  various  prime  contractors  or  from  the  lack  of  priority  assigned  to  the 
SIAP  effort  by  the  various  Service  resource  OPRs. 

We  have  already  learned  many  lessons  from  the  Block  0  effort.  The  Services  do 
not  develop  cost  estimates  for  engineering  and  implementation  for  interface  changes. 
Additionally,  the  Services  do  not  have  sufficient  engineering  evidence  to  support  the 
changes  that  are  approved  through  the  JINTACCS  process  to  meet  the  burden  of  proof 
requirement  levied  on  us. 


Recommendation:  Direct  Services  to  provide 
appropriate  funding  and  priority  to  prepare  budget 
level  estimates  and  high  level  program  schedules 
required  to  implement  FoS  JDN  fixes. _ 
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3.  SPECIFIC  PLANS 


In  this  section  of  the  report,  we  address  the  three  specific  issues  discussed  in  the 
tasking  memo.  After  a  brief  introduction  to  establish  context,  we  begin  by  describing  the 
plan  to  develop  and  maintain  the  SIAP  Integrated  Architecture.  We  then  describe  the 
plan  to  improve  the  capability  of  existing  systems  to  operate  together  (“fix  the  JDN”), 
and  end  with  a  brief  description  of  the  plan  to  define  the  “JCTN”. 

These  three  specific  issues  are  tightly  coupled  -  the  SIAP  Integrated  Architecture 
is  the  framework  for  the  “JDN”  and  the  “JCTN”  issues,  and  all  must  be  tied  back  to 
JROC-validated  Capstone  Requirements  Documents  (TAMD,  CID,  IDM,  and  GIG). 

We  are  operating  under  several  fundamental  premises: 

•  A  quality  product  obtains  from  a  quality  process,  so  building  and  maintaining  a 
quality  process  is  critical  to  providing  the  required  level  of  capability. 

•  There  is  no  "silver  bullet"  to  the  "interoperability"  challenge  -  only  a  robust, 
disciplined  system  engineering  process  will  provide  the  required  level  of 
performance. 

•  The  Department  of  Defense  (DoD)  does  not  have  the  resources  necessary  to 
have  healthy  competing  programs  —  some  convergence  is  needed  to  provide 
lifecycle  cost  avoidance. 

•  We  do  not  have  the  resources  to  start  from  a  “clean  sheet  of  paper”  -  we  must 
leverage,  and  extend  as  necessary,  work  that  has  been  done  before. 

•  An  incremental  ("spiral")  approach  to  providing  warfighting  capability  is  the 
only  viable  course  of  action.  We  have  neither  time  nor  resources  to  wait  for 
the  "better"  solution. 

Improving  joint  warfighting  capability  is  a  task  with  several  hard  constraints: 

•  The  DoD  has  a  significant  investment  in  existing  systems,  with  attendant 
equipments,  computer  programs,  and  infrastructure.  The  vast  majorities  of  the 
systems  that  will  be  in  service  in  2010  are  either  in  service  today  or  are  in 
development  and  will  enter  service  in  the  foreseeable  future. 

•  Joint  warfighting  requirements  must  compete  against  Service-specific 
requirements  for  scarce  (Seryice)  resources  (e.g.,  dollars  and  people). 

•  The  DoD  will  operate  with  forces  provided  by  other  nations,  so  system 
engineering  efforts  must  account  for  allied  and  coalition  operations. 

Making  progress  depends  upon  balancing  conflicting  demands  in  this 
constrained  environment.  Progress  is  made  more  difficult  because  the  Department  of 
Defense  does  not  yet  have  enterprise  architecture  for  joint  theater  air  warfare. 

Although  interoperability  tests  and  exercises  to  date  have  been  disparate  and 
focused  on  objectives  not  directly  related  to  the  SIAP,  conventional  wisdom  suggests 
that  the  “JDN”  must  be  significantly  improved  while  a  “JCTN”  or  its  equivalent  capability 


42 


is  also  required  to  meet  JROC-validated  capstone  requirements  for  theater  air  and 
missile  defense  and  combat  identification.  It  is  generally  accepted  that  the  approach 
that  makes  the  most  sense  fixes  problems  in  the  “JDN”  while  either  augmenting  it  with 
additional  bandwidth  (or  otherwise  increase  effective  throughput)  or  adding  a  new 
network.  The  Task  Force  will  follow  the  technically  correct  path  while  ensuring  a  sound 
methodology  so  that  alternative  approaches  can  be  identified  with  appropriate 
acquisition  rigor  to  find  a  solution  acceptable  to  the  Services. 

3.1.  SIAP  INTEGRATED  ARCHITECTURE 

The  14  November  1996  memorandum  that  discussed  the  management  of 
Theater  Air  and  Missile  Defense  activities  (Appendix  B)  directed  that  a  TAMD  Integrated 
Architecture  (lA)  be  generated.  The  memo  directed  JTAMDO  to  “coordinate  with  the 
Warfighting  CINCs  and  Military  Services  to  develop  joint  mission  capstone 
requirements,  a  Joint  mission  architecture,  and  a  joint  capabilities  roadmap.”  BMDO 
(now  MDA)  was  directed  to  “assume  the  role  of  integration  Systems  Architect  for 
Theater  Air  and  Missile  Defenses.”  MDA  was  also  directed  to  “working  with  JTAMDO 
and  the  Services, .  . .  translate  the  JTAMDO  developed  operational  architecture  into 
systems  architectures,  perform  system  engineering  at  the  architecture  level,  plan  and 
ensure  integrated  testing  of  defense  architectures,  and  lead  program  acquisition 
activities.” 

The  TAMD  and  CID  CRDs  were  validated  by  the  JROC  in  March,  2001;  these 
documents  constitute  the  mission  capstone  requirements  for  TAMD.  JTAMDO  will 
deliver  the  first  iteration  of  the  Operational  Views  of  the  TAMD  lA  in  October,  2001 .  The 
TAMD  lA  will  include  the  Joint  Capabilities  Roadmap. 

BMDO  began  work  on  the  system  and  technical  views  during  FY  00.  BMDO  was 
scheduled  to  deliver  the  system  and  technical  views  of  the  TAMD  lA  in  the  fourth 
quarter  of  FY  02.  Because  BMDO’s  role  in  TAMD  changed  during  FY01 ,  BMDO 
abandoned  the  effort  for  generation  of  the  system  and  technical  views  of  the  TAMD  lA. 

The  SIAP  SE  Task  Force  Charter  recognizes  the  importance  of  the  TAMD 
Integrated  Architecture  and  provides  the  specific  tasking  shown  in  figure  9. 


(9)  Support  the  JTAMD  process  in  developing  the  operational 
views  of  the  TAMD  integrated  architecture. 

(10)  Supported  by  the  JTAMD  process,  use  a  disciplined  system 
engineering  process  to  develop  the  system  and  technical  views 
of  the  SIAP  component  of  the  TAMD  integrated  architecture,  to 
include  an  overall  time-phased  development  and  deployment 
schedule,  ensuring  this  work  is  consistent  with  and  supports 
the  operational  views  of  the  TAMD  integrated  architecture. 
Ensure  the  work  to  define  the  system  views  is  consistent  with 
and  supports  the  common  operational  picture/common  tactical 
picture  “family  of  interoperable  operational  pictures”  initiative. 
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Figure  9.  Interaction  with  the  JTAMD  Process 

We  are  working  closely  with  JTAMDO  to  develop  the  SIAP  component  of  the 
TAMD  lA.  To  strengthen  this  team  effort,  and  to  facilitate  communication,  we  have 
collocated  the  architecture  efforts  of  JTAMDO  and  the  SIAP  SE  Task  Force.  This 
collocation  effort  has  greatly  improved  communication  and  teamwork. 

To  reduce  confusion  within  this  document,  and  to  remain  consistent  with  the 
tasking  memo,  the  term  “SIAP  Integrated  Architecture”  refers  to  an  architecture  that 
extends  beyond  the  TAMD  lA  to  cover  the  entire  aerospace  domain,  while  not  covering 
that  portion  of  the  TAMD  lA  that  does  not  specifically  relate  to  objects  in  the  aerospace 
volume.  Figure  10  graphically  represents  the  relationship  between  the  SIAP  and  TAMD 
lAs  and  shows  the  activity  that  has  the  lead  to  develop  specific  architectural  views. 
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Figure  10.  Relationship  between  SIAP  and  TAMD  Integrated  Architecture 


The  TAMD  lA  will  define  an  objective  capability  that  is  essential  to  achieve  the 
required  levels  of  TAMD  and  CID  warfighting  capability.  The  lA  is  a  key  analysis  tool 
that  provides  a  structured  means  to  document  the  results  of  the  system  engineering 
process  and  act  as  a  control  mechanism  to  indicate  where  analysis  is  missing  or  further 
analysis  is  needed.  The  lA  is  a  technical  repository  for  characterizing  a  SIAP  and  forms 
the  technical  context  for  performing  repeatable  analysis.  All  our  analysis  and  lA 
development  efforts  are  mutually  supportive  for  building  a  disciplined  system 
engineering  process. 


Recommendation:  Joint  Staff  J-8  assign  to 
JTAMDO  the  responsibility  and  resources  necessary 
to  complete  the  operational  views  of  the  SIAP  lA 


The  SIAP  lA  specifically  includes  the  processing,  management,  and 
dissemination  of  combat  identification  information.  Additionally,  because  the  SIAP  is  an 
enabler  of  joint  warfighting  capability,  and  because  it  must  support  the  most  stringent 
JROC-validated  joint  warfighting  requirement,  it  must  be  engineered  to  meet  the 
requirements  for  integrated  fire  control  and  advanced  battle  management  aids 
articulated  in  the  TAMD  CRD. 
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As  we  have  worked  with  JTAMDO  in  building  both  the  SIAP  lA  and  the  TAMD  lA, 
we  realized  the  need  to  solicit  industry  invoivement.  We  recognize  that  the  capability  to 
build  and  maintain  a  SIAP  will  only  be  achieved  through  the  fielding  of  safe  and  effective 
people,  equipment,  computer  programs,  and  operating  procedures.  The  equipment  and 
computer  programs  are  developed  and  maintained  by  our  industrial  partners.  Having 
industry  involved  early  and  often  gives  them  insight  into  the  direction  toward  which  we 
are  heading  and  allows  us  to  solicit  and  understand  their  suggestions  and  concerns. 

We  are  working  with  JTAMDO  to  hold  a  series  of  workshops  with  industry  (co¬ 
sponsored  by  the  Nationai  Defense  Industry  Association).  These  workshops  will  allow, 
in  a  carefully  controlled  environment,  for  a  full  and  open  discussion  on  the  evolving 
SIAP  Integrated  Architecture. 

The  SIAP  lA  must  be  maintained  (updated  and  configuration  managed)  as  joint 
requirements  change  and  as  emerging  capabilities  are  engineered  and  fielded. 

Recommendation:  USD(AT&L)  formally  assign  an 
activity  to  budget  for,  update  and  manage  the 
configuration  of  the  SIAP  Integrated  Architecture. _ 


3.1.1.  Objectives 

The  SIAP  I A  serves  several  key  functions.  First,  it  allows  us  (warfighters  and 
engineers)  to  communicate  amongst  ourseives.  It  shows,  in  graphical  and  tabular  form, 
how  we  intend  to  fight  by: 

•  describing  interrelationships  among  warfighting  units, 

•  describing  the  functions  that  warfighting  units  wiil  perform  individuaily  and 
coliectively,  and 

•  defining  how  well  those  functions  must  be  performed  to  satisfactorily 
accomplish  the  assigned  mission  in  an  acceptable  way. 

The  integrated  architecture  supports  informed  decision-making.  It  helps  identify 
the  existence  of  functionai  gaps,  overlaps,  and  conflicts,  and  provides  a  framework  for 
issue  resolution.  The  lA  exposes  interreiationships  so  we  can  better  understand  the 
impact  of  individual  component  or  system  changes  on  the  capability  of  the  iarger  system. 

The  lA  provides  a  structured  means  to  document  the  results  of  the  system 
engineering  process.  The  lA  is  also  a  shared  repository  of  system  engineering  artifacts. 

It  is  a  control  mechanism,  supported  by  modeling  and  simulation,  to  indicate  where 
anaiysis  is  missing  or  further  analysis  is  needed. 

Additionaliy,  the  architecture  forms  a  contract  between  the  warfighter  and 
acquisition  communities,  and  ailows  us  to  communicate  with  industry. 

The  SIAP  lA  defines  an  objective  capability  needed  to  attain  JROC-validated 
TAMD  and  CID  warfighting  capabilities.  The  SIAP  lA  supports  traceability  of 
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requirements  from  CJCS  Joint  Vision  2010  and  2020,  TAMD  and  CID  CRDs,  IDM  CRD. 
GIG  CRD,  and  the  JTAMD  2010  Operational  Views,  to  system  functions.  Information 
Exchange  Requirements  (lERs),  and  a  system-level  physical  data  model.  This 
requirements  traceability  provides  a  coherent  audit  trail  from  integrated  operational 
requirements  and  measures  of  effectiveness  (MOEs)  to  the  specific  technical  criteria 
governing  the  development  of  a  SIAP  capability. 

The  SIAP  lA  is  the  product  that  defines  the  joint  interfaces,  functional  and 
allocated  baselines,  and  the  associated  information  exchange  requirements  (IERs)/data 
models,  and  serves  as  the  basis  for  SIAP  implementation  trades  and  requirements 
allocation.  This  product  supports  developers,  testers,  and  is  the  tool  for  enforcing 
integrated  implementation  of  SIAP  functional  requirements.  Architecture  products,  such 
as  the  System  Capability  Evolution  Description,  will  describe  the  key  elements  of  the 
Block  Improvement  Plans  that  are  a  key  decision  document  for  JROC  endorsement  to 
proceed  with  implementation  of  each  SIAP  block  upgrade. 

The  SIAP  lA  provides  Justification  for  Service  and  Agency  investment  in  legacy, 
emerging,  and  future  systems  to  achieve  a  SIAP  capability.  This  roadmap  will  be 
integrated  with  the  Joint  Capabilities  Roadmap  and  the  Joint  Acquisition  Roadmap  that  is 
now  being  generated  by  JTAMDO  and  MDA  with  SIAP  SE  TF  support.  The  SIAP  lA  will 
be  used  to  establish  and  enforce  the  integrated  fielding  of  SIAP  functional  requirements 
within  a  TAMD  lA  context.  It  will  focus  on  the  issues  of  interconnecting  systems  and 
organizations  at  the  Service-to-joint,  joint-to-joint,  and  Joint  Task  Force  (JTF)-to-ally 
levels  of  interoperability.  The  SIAP  lA  will  provide  sufficient  guidance  to  system 
architects  and  engineers  to  ensure  their  systems  conform  to  the  information  processing 
and  sharing  requirements  of  the  JTF. 

In  the  remainder  of  this  section,  we  briefly  discuss  some  of  the  terms  associated 
with  the  SIAP,  describe  the  motivation  for  the  SIAP,  outline  the  concept  of  operations, 
and  discuss  specific  SIAP  and  SIAP-related  requirements. 

3.1. 1.1.  Definitions 

In  this  section,  we  briefly  discuss  the  definitions  of  some  of  the  terms  associated 
with  the  SIAP,  and  some  of  the  problems  that  arise  from  the  definitions. 

While  use  of  the  terms  Joint  Planning  Network  (JPN),  Joint  Data  Network  (JDN), 
and  Joint  Composite  Tracking  Network  (JCTN)  are  used  frequently,  there  is  no  widely-’ 
accepted  detailed  definition  for  any  of  these  networks.  That  deficiency  was  recognized 
in  the  SIAP  SE  charter: 

“c.  This  charter  recognizes  the  fluid  nature  of  present  concept 
definitions  such  as  joint  planning  network  (JPN),  joint  data  network  (JDN), 
and  joint  composite  tracking  network  (JCTN).  The  SIAP  SE  will  assist  the’ 

Joint  Theater  Air  and  Missile  Defense  Organization  (JTAMDO)  in  defining 
these  terms  and  will  ensure  the  system  engineering  process  is 
responsive  to  the  evolution  of  concepts  such  as  these.  An  initial  focus  of 
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the  organization  will  be  on  establishing  recommendations  for  near-term 
JDN  improvements  on  the  path  to  a  SIAP  capability.” 

In  general,  each  of  these  networks  is  comprised  of  operators,  computers, 
computer  programs,  and  communications  equipment,  and  is  intended  to  satisfy  specific 
operator  needs  and  requirements.  There  are  several  complicating  factors  associated 
with  these  networks: 

•  Similar,  and  in  some  cases,  identical  information  is  exchanged  among 
operators  and  computers  over  two  or  more  networks  asynchronously.  This 
results  in  operator  confusion  and  system  failure  due  to  data  loops  and  race 
conditions. 

•  The  computers,  computer  programs,  and  communications  equipment  used  in 
each  of  these  networks  are  independently  resourced  and  acquired  by  different 
services/agencies  to  meet  specific  requirements,  often  unrelated  to  their 
performance  as  part  of  a  network. 

The  JPN  is  described  in  the  1999  TAMD  Master  Plan: 

"The  Joint  Planning  Network  (JPN)  is  the  collection  of  non  real  time  and 
near  real  time  communications  and  information  systems  used  to  carry  out 
TAMD  planning  throughout  the  theater.  It  provides  a  distributed 
collaborative  planning  capability,  automated  battle  management  aids,  and 
a  means  for  distributing  plans  within  the  theater.  The  core  of  the  JPN  is 
the  Global  Command  and  Control  System  (GCCS)  operating  in  the 
Defense  Information  Infrastructure  Common  Operation  Environment  (Dll 
COE).  The  Joint  Defensive  Planner  and  elements  of  the  Theater  Battle 
Management  Core  System  running  on  GCCS  platforms  provide  the 
foundation  for  TAMD  planning  tools."  [1999  TAMD  Master  Plan] 

The  JDN  is  described  in  at  least  two  documents: 

The  Joint  Data  Network  (JDN)  is  a  network  of  operators,  computers,  and 
communication  systems  that  carries  tactical  command  and  control 
information  within  the  theater  in  support  of  joint  theater  air  missile  defense, 
and  attack  operations  in  the  form  of  counter-air,  interdiction,  close  air 
support  (CAS),  suppression  of  enemy  air  defense  (SEAD),  and  time- 
critical  targeting  (TCT)  prosecution.  Information  is  generally  exchanged  via 
the  JDN  in  near-real-time.  [CJCSM  3115.01,  1  Oct  2000] 

The  JDN  is  the  collection  of  near  real  time  communications  and 
information  systems  used  primarily  at  the  coordination  and  execution 
levels.  It  provides  information  exchange  necessary  to  facilitate  the  joint- 
Service  battle  manager's  comprehension  of  the  tactical  situation  and 
provides  the  means  to  exercise  C2  beyond  the  range  of  organic  sensors. 

JDN  carries  near  real  time  tracks,  unit  status  information,  engagement 
status,  coordination  data,  and  force  orders.  JDN  can  provide  information 
to  cue  sensors  as  well.  The  backbone  of  JDN  is  Link  1 6  transmitted  via 
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JTIDS  and  MIDS  terminals.  However,  other  data  links  such  as  TADIL  A, 

B,  or  C,  Link  22,  and  Variable  Message  Format  (VMF)  will  exchange 
information  with  JDN  through  gateways  at  various  platforms  to  ensure  that 
all  participating  users  are  included  in  the  JDN  forTAMD.  Satellites  link 
geographically  dispersed  users  in  near  real  time  without  consuming  limited 
tactical  bandwidth.  [TAMD  Master  Plan,  1 999] 

The  JCTN  is  described  in  CJCSM  31 15.01: 

The  Joint  Composite  Tracking  Network  (JCTN)  is  a  tracking  fusion 
network  supporting  system-to-system  exchange  of  multi-sensor  data  in 
real-time.  The  JCTN  supports  systems  and  firing  units  in  the  real-time 
detection  and  engagement  of  tactical  threats.  The  JCTN  provides  systems 
and  firing  units  real-time  exchange  of  precision  sensor  measurement  data 
and  weapons  engagement  signals  to  conduct  engagements  in  real  time. 

[CJCSM  3115.01,  1  Oct  2000] 

There  are  several  differences  between  the  JDN  and  JCTN  that  are  important  to 
understand.  First,  the  purposes  of  these  two  networks  are  different.  The  JDN  is  used 
to  exchange  messages  that  focus  on  near-real-time  elements  of  situational  awareness 
and  mission  execution.  The  JCTN’s  primary  purpose  is  to  exchange  measurements 
and  to  subsequently  “fuse”  those  measurements  to  ensure  that  there  is  a  single  track  for 
each  aerospace  object;  composite  tracks  will  be  at  least  as  accurate  as  each  of  the 
individual  systems  contributing  to  the  track  of  a  particular  object.  In  addition,  the 
anticipated  JCTN  will  require  significant  communications  bandwidth  to  communicate 
necessary  data  from  each  sensor  to  all  destination  nodes  in  the  battlefield  where  data 
fusion  processing  must  occur;  this  will  create  a  greater  load  on  communication  networks 
than  what  JDN  imparts  today.  As  a  result,  it  is  generally  agreed  that  additional 
bandwidth  will  be  required  to  realize  the  JCTN  or  to  at  least  Implement  its  functionality 
within  the  current  JDN  concept. 

We  recognize  the  technical  problems  associated  with  these  definitions  and  will 
resolve  the  ambiguity  through  the  system  engineering  process  by  which  we  develop  the 
SIAP  Integrated  Architecture. 

Debate  on  the  definition  of  these  terms  is  consuming  resources  that  can  better 
be  used  toward  characterizing  the  functions  that  must  be  accomplished  to  meet  JROC- 
validated  requirements.  Following  a  disciplined  approach  to  defining  the  networks  in 
terms  of  the  functions  they  perform  will  clearly  show  functional  gaps,  overlaps,  and 
conflicts.  We  will  develop  candidate  solutions  for  these  problems  and  will  take  specific 
recommendations  forward  to  the  JROC  for  validation. 
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Recommendation:  USD(AT&L)  defer  the  SlAP  SE 
Charter  requirement  to  define  the  terms  Joint  Planning 
Network  (JPN),  Joint  Data  Network  (JDN),  and  Joint 
Composite  Tracking  Network  (JCTN)  until  the  functional 
and  allocated  baselines  have  been  established  in  the 
SlAP  Integrated  Architecture.  _ 


3.1. 1.2.  Contribution  of  the  Single  Integrated  Air  Picture 

The  Department  of  Defense  has  been  connecting  individual  warfighting  units 
using  communication  networks  for  many  years.  Initial  efforts  focused  on  sharing 
information  over  relatively  low  data  rate  communication  channels  for  the  purpose  of 
building  shared  situational  awareness.  Operators  were  able  to  exploit  this  information  to 
pair  interceptors  (aircraft  and  missiles)  to  potential  targets  in  an  attempt  to  increasing 
the  effective  firepower  available  by  extending  the  battlespace. 

Increases  in  effective  throughput,  provided  by  advances  in  technology,  have 
allowed  the  expansion  of  the  number  of  nodes  on  these  communication  networks. 
Increasing  the  number  of  nodes  should  provide  increasing  levels  of  warfighting 
capability.  These  increases  have  not  been  realized,  however,  because  of  the  way  in 
which  network  functionality  has  been  specified,  implemented,  and  verified.  The  U.  S. 
Department  of  Defense  is  on  a  path  to  resolve  many  of  these  issues  and  to  realize  the 
benefits  promised  through  the  interconnection  of  existing  and  emerging  systems.  Many 
significant  warfighting  benefits  are  expected  through  effective  networking  of  individual 
warfighting  units;  these  include: 

•  Better  and  faster  weapon-pairing  decisions 

•  Reduced  risk  of  fratricide 

•  Improved  weapon  utilization  by  minimizing  fire  control  track  breaking,  enabling 
more  engagement  opportunities,  and  providing  more  accurate  target  handover 
at  endgame. 

•  Increased  weapon  effectiveness  and  battlespace  -  Negate  the  threat 
before  weapons  are  allocated 

•  Reduced  weapon  expenditure  -  improve  weapon-target  pairing  so  multiple 
units  can  coordinate  fires 

•  Reduced  collateral  damage  -  understand  the  location  of  combatants  and 
non-combatants 

•  Increased  battlespace  and  depth  of  fire  by  providing  more  engagement 
decision  time,  by  enabling  earlier  weapon  launch  and  supporting  guidance  on 
remote/composite  track/data,  and  by  allowing  handover  of  interceptor  missile 
control  among  participating  weapon  units. 

•  Robust  counter-countermeasures  and  enhanced  survivability  by  exploiting 
sensor  frequency,  viewing-angle,  and  Doppler  diversity  against  low  observable 
targets  by  using  sensor  frequency  and  viewing-angle  diversity,  triangulation, 
and/or  burnthrough  by  the  most  appropriate  radar  against  escort  and  self¬ 
screening  jammers:  and  by  enabling  engagements  by  weapon  units  when  their 
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own  fire  control  sensor  is  inoperative  or  employing  emission  control  (EMCON) 
tactics. 

•  Increased  flexibility.  Warfighters,  at  all  levels  of  the  chain  of  command,  have 
more  flexibility.  Individual  units  have  increased  depth  of  fire,  allowing  them  to 
commit  assets  earlier. 

•  Improve  ability  to  choose  when/where  engagements  occur.  Fight  on  our 
terms,  not  the  enemy’s. 

•  Lessen  restrictions  caused  by  non-interoperability. 

•  Enhanced  operational  flexibility  by  providing  robustness  against  unforeseen 
threat  trajectories  and  maneuvers,  by  facilitating  deployment  of  surveillance 
sensors  to  optimize  theater-level  coverage  without  sacrificing  critical  defended 
asset  coverage,  and  by  supporting  advanced  joint  concepts  using  remote 
weapon  launch  sites. 

•  Improved  interoperability  with  Allies/Coalition  partners 

•  Better  coordination  of  action. 

•  Improved  sense  of  inclusion  and  partnership. 

•  Improved  individual  situational  awareness 

•  Reduced  operator  workload.  With  better  situational  awareness,  warfighters 
can  concentrate  on  exceptions,  rather  than  on  every  object  in  the 
battlespace. 

•  Enhanced  joint  composite  identification  (ID)  data  exploitation  through 
improved  track  identification  continuity,  through  improved  local  track-to- 
network  track  association,  and  through  dissemination  and  fusion  of 
participant  sensor-derived  identification  information. 

•  Better  raid  count  through  composite  resolution  of  closely  spaced  air 
vehicles  with  data  from  more  than  one  sensor. 

•  Improved  collective  situational  awareness.  Sensor  Information,  shared 
among  participants,  extends  shared  situational  awareness.  Warfighters  can 
understand  not  only  what  is  in  their  immediate  area,  but  what  is  happening  in 
adjacent  areas  that  may  soon  affect  them  or  units  upon  whom  they  depend. 
Scarce  resources,  such  as  sensors  and  interceptors,  can  be  allocated  to 
regions  or  threats  of  greatest  need.  When  shared  information  is  reliable, 
warfighters  can  use  this  information  to  make  more  timely  decisions,  which 
extends  the  battlespace  available. 

•  Less  confusion 

•  Better  discrimination 

•  Improved  sensor  resource  utilization  through  sharing  of  surveillance  coverage 
responsibilities  among  participating  joint  sensors,  leveraging  the  special 
resolution  and  discrimination  capabilities  of  particular  sensor  types,  and 
enabling  fire  control  track  to  be  attained  and  maintained  with  less  expenditure 
of  sensor  resources. 

3.1.1.3.  Concept  of  Operations 

The  SIAP  must  support  the  spectrum  of  offensive  and  defensive  operations  by 
U.S.,  allied,  and  coalition  partners  in  the  aerospace  volume  within  a  theater  of 
operations.  The  SIAP  is  recognized  as  being  a  product  used  by  many  elements  outside 
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the  Joint  Theater  Air  and  Missile  Defense  (JTAMD)  community.  SIAP  will  be  built  both 
from  sources  under  the  control  of  the  Joint  Task  Force  Commander  and  other  relevant 
information.  SIAP  will  be  provided  for  all  joint  mission  areas  where  consumers  exist, 
such  as  airspace  management  and  Joint  Forces  Air  Component  Commander  (JFACC) 
mission  areas  involving  the  tactical  employment  of  air  power.  As  such,  the 
requirements  for  SIAP  are  dominated  by  the  JTAMD  community,  but  also  include  other 
taskforce  constituents,  requirements,  and  the  architecture  must  be  sufficiently  robust  to 
ensure  that  these  external  elements  have  access  to  the  SIAP.  The  SIAP  lA  will 
encompass  interfaces  with  SIAP  information  sources,  the  production  of  SIAP 
processes,  and  interfaces  with,  and  applications  support  to,  SIAP  consumers. 

In  its  most  fundamental  form,  the  SIAP  is  composed  of  information  on  air  and  space 
objects  of  all  types,  friendly,  hostile,  and  unknown.  Much  of  the  information  is  gathered 
by  individual  active  and  passive  sensors.  SIAP  information  on  friendly  vehicles  is  often 
actively  broadcast  by  those  platforms,  using  a  variety  of  means.  The  basic  intent  of  the 
SIAP  concept  is  to  distribute  SIAP-related  information  from  off-board  sources  to  other 
units  in  theater  to  enhance  their  situational  awareness  and  warfighting  effectiveness. 

Any  tactical  unit  in  a  theater,  which  may  have  to  interact  with,  or  be  aware  of,  air 
or  space  objects,  has  a  need  for  SIAP  information.  The  quantity  and  quality  of  SIAP 
information  needed  by  any  specific  unit  depends  on  its  type,  mission,  and  the  mission 
phase.  Many  in-theater  sensors  contribute  information  to  the  SIAP  from  both  active  and 
passive  sensors.  In  addition,  SIAP  information  can  originate  from  sensors  outside  the 
theater.  It  can  also  be  self-generated,  as  in  the  case  of  unit  position  and  status  reports. 
All  of  this  information  on  aerospace  objects,  when  distributed  to  the  right  units  at  the 
right  time  can  enhance  mission  effectiveness. 

The  primary  means  for  distributing  SIAP  information  is  by  Tactical  Data  Links 
(TDLs).  Tactical  data  links  provide  technology-based  implementation  to  satisfy 
information  exchange  requirements.  C4I  is  the  framework  for  situational  awareness, 
decision-making,  and  execution  throughout  the  battlespace.  Efficient  execution  of 
information  exchange  requirements  throughout  the  joint  battlespace  is  key  to  evolving 
C4I  toward  the  ultimate  goal  of  seamless  information  exchange.  The  primary 
component  of  this  infrastructure  is  the  C4I  TDL  comprised  of  data  elements/messages 
and  physical  media.  No  single  TDL  supports  every  C4I  system  oris  able  to  operate  in 
all  battlefield  environments  (JTDLMP).  The  Joint  Tactical  Data  Link  Management  Plan 
has  cognizance  over  18  separate  TDLs.  These  18  TDLs  include  the  J-Series  Family  of 
TDLs  i.e..  Link  16,  Link  22,  and  Variable  Message  Format  (VMF)  TDLs.  CINCs, 

Services  and  Agencies  developing  TDL  systems  must  comply  with  DoDD  4630.5  as 
amplified  by  the  18  October  1994  ASD(C3I)  Memorandum,  “C3I  Tactical  Link  Policy.” 
This  memorandum  “designates  the  U.S.  agreed  Link  16  data  link  as  the  DoD  primary 
tactical  data  link  for  all  Service  and  Defense  Agency  Command  and  Control  (C2), 
Intelligence  (I). . .” 

Link  16  uses  a  single-best-sensor  reporting  scheme  for  objects  in  a  broad-brush 
moderate  quality  situational  awareness  (SA)  data  distribution  scheme  that  typically  is 
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widely  distributed.  This  relatively  low  fidelity  wide-area  data  distribution  can  be 
augmented  with  special  high  fidelity  data  distributions  to  support  specific  warfighting 
functions  that  require  higher  performance  and  resolution.  These  high  quality  data 
exchanges  are  typically  confined  to  a  small  number  of  platforms,  which  have  a  need  for 
such  high  quality  data.  On  Link  16,  this  type  of  limited  distribution  is  called  a  subnet. 
The  distribution  limitations  of  the  subnets  are  an  integral  part  of  the  methodology  by 
which  Link  16  attempts  to  efficiently  use  its  limited  bandwidth. 

There  are  other  highly  capable  data  distribution  systems,  which  are  expected  to 
play  an  important  role  in  the  creation  of  a  SIAP.  These  are  the  composite  tracking 
systems  such  as  the  Navy’s  Cooperative  Engagement  Capability  (CEC),  and  the 
conceptual  extension  of  CEC  into  the  joint  environment  under  the  title  of  the  Joint 
Composite  Tracking  Network  (JCTN).  In  the  context  of  the  overall  theater  SIAP 
architecture,  the  high  quality  composite-tracking  distributions  are  similar  to  the  high¬ 
speed  subnets  of  Link  16.  It  is  likely  that  the  SIAP  architecture  of  the  near  future  will  be 
some  combination  of  the  moderate  quality  Link  16  wide  area  distributions,  higher  quality 
Link  16  subnet  distributions,  and  still  higher  quality  composite  tracking  distributions.  In 
the  more  distant  future,  it  is  likely  that  a  continuing  migration  toward  more  composite 
tracking  will  prevail,  provided  methods  for  keeping  bandwidth  requirements  within 
realizable  access  limits  can  be  found. 

A  common  question  is,  “How  much  SIAP  is  enough?”  The  answer  is  different  for 
different  units.  Warfighting  needs  differ  from  units  to  units  and  from  one  mission  and 
mission  phase  to  another.  Therefore,  ‘enough’  SIAP  means  different  data  for  different 
units  at  different  times,  i.e.,  a  ‘tailored’  picture.  Testing  for  ‘enough’  SIAP  thus  becomes 
a  test  of  time-varying  data  requirements  versus  time-varying  data  delivery.  It  means 
that  sometimes,  for  some  units  group  tracks  are  fine,  and  it  means  that  at  other  times, 
individual  breakouts  are  required.  Success  is  when  the  SIAP  provides  the  data  in  the 
quantity  and  quality  needed  to  perform  a  particular  mission.  Success  with  excess  (i.e., 
providing  much  more  data  than  is  needed  to  perform  a  mission  or  function) 
unnecessarily  consumes  bandwidth,  which  could  result  in  a  loss  of  functionality  or 
performance  elsewhere,  or  loss  of  growth  potential  for  the  system,  either  of  which 
makes  ‘success  with  excess’  a  less  desirable  than  a  more  efficient  result. 

3.1. 1.4.  Single  Integrated  Air  Picture  Requirements 

The  Department  of  Defense  is  building  a  networked  joint  warfighting  capability  by 
inter-connecting  a  large  number  of  existing  systems.  Each  of  these  systems  is  carefully 
engineered  and  managed  to  meet  specific  operational  requirements.  Each  are 
comprised  of  many  subsystems  that  are  engineered  and  built  to  requirements  and 
specifications  that  derive  from  system-level  operational  requirements.  The  subsystems 
interact  through  carefully  managed  interfaces.  The  combination  of  functions  and 
interfaces  express  the  capability  provided  by  the  system. 

Exacerbating  this  situation  has  been  the  lack  of  an  outcome-based  overarching 
requirement  for  the  capability  needed  by  the  joint  warfighter.  The  Theater  Missile 
Defense  Capstone  Requirements  Document,  which  was  validated  by  the  JROC  in  July 
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1999,  went  a  long  way  toward  resolving  this  shortfall.  Considerable  effort,  involving 
many  people,  went  into  developing,  vetting,  and  validating  the  TAMD,  CID,  IDM,  and 
GIG  Capstone  Requirements  Documents. 

As  previously  articulated,  SIAP  requirements  are  documented  in  several  sources: 
TAMD  and  CID  CRDs,  the  IDM  CRD,  the  GIG  CRD,  and  other  relevant  operational 
requirements  documentation  such  as  specific  program  requirements.  This  set  of 
documents  describes  the  “top-down”  requirements  that  are  relevant  to  the  SIAP.  Later 
we  will  discuss  the  existing  interface  standards  that  comprise  the  "bottom-up" 
requirements. 

SIAP  is  a  key  performance  parameter  in  the  TAMD  CRD  (Table  7): 

_ _ Table  7:  Excerpt  from  TAMD  CRD  (U) _ 

(U)  Key  Performance  Parameter:  SINGLE  INTEGRATED  AIR 
PICTURE  (SIAP) 

a.  (U)  Criteria:  Designated  applicable  TAMD  FoS  sensor 
systems  intended  to  surveil,  detect,  and  track  air  objects 
must  contribute  to  a  SIAP.  The  SIAP  (the  air  track 
portion  of  the  common  tactical  picture  (CTP))  consists  of 
common,  continuous,  and  unambiguous  tracks  of  airborne 
objects  of  interest  in  the  surveillance  area.  SIAP  is 
derived  from  real  time  and  near  real  item  data  and 
consists  of  correlated  air  object  tracks  and  associated 
information.  SIAP  requirements  are  as  follows: 

(1)  (U)  The  SIAP  must  be  scaleable,  filterable,  and 
support  situation  awareness  and  battle 
managements. 

(2)  (U)  Objectively,  each  object  must  have  one,  and  only 
one,  track  identifier  and  associated  characteristics. 

(3)  (U)  SIAP  minimal  acceptable  attributes  and  metrics  are 

_ provided  in  Table  IV-5  (see  below) _ 
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Table  8:  SIAP  Requirements 


UNCLASSIFIED 

Attribute 

Metric 

Completeness 

XX%(T),  XX%  (0)  of  ground  truth  threat  objects  detected 
and  tracked  upon  entering  area  of  influence  (TBR)  XX%  (T), 
XX%  (0)  of  ground  truth  aircraft  detected  and  tracked  upon 
entering  area  of  influence  (TBR)  Available  and  exploitable 
by  XX%  of  primary/secondary  systems  available  to  JFC 
(TBR) 

Ambiguity 

Average  X.X  (T),  X.X  (0)  SIAP  tracks  per  air  object 
(TBR)  XX%  (T),  XX%  (0)  of  tracks  represent  distinct  ground 
truth  objects  (TBR) 

Continuity 

Track:  XX  minutes  (T),  XX  minutes  (0)  without  any  track 
drops,  duals/splits,  merges,  or  swaps  (TBR) 

Timeliness 

See  Interoperability  KPP 

UNCLASSIFIED 

(U)  Table  IV-5:  SIAP  Requirements 

CID  CRD:  Accurate  classification  and  identification 


Key  Performance 
Parameter 

Threshold 

Objective 

Identification 

Probability: 

Of  all  detected 
friendly 

objects/entities 

XX% 

XX% 

Of  all  detected 
enemies 
objects/entities 

XX% 

XX% 

Of  all  detected 
neutral  objects. 

XX% 

XX% 

IDM  CRD:  Part  of  the  Global  Information  Grid  (GIG),  IDM  establishes 
requirements  for  data  dissemination  pertaining  to  primary  backbone  networks, 
communications  pathways,  data  bases,  and  computer  systems  at  the  tactical  ’ 
level  and  above.  The  principal  area  of  applicability  to  SIAP  is  data  transmission, 
spanning  information  access  and  information  delivery,  along  with  consideration  of 
"survival"  and  "planning"  criteria  tied  to  real  time  and  non-real  time  data. 


Table  9:  Excerpt  from  IDM  CRD  (U) 


CAPABILITIES 

KPP 

REQUIREMENTS 

Interoperability 

4 

Satisfy  100%  of  critical  lERs  to  the  threshold 
level  (Threshold  KPP).  Satisfy  100%  of  lERs  to 
the  objective  level  of  the  attributes  (Objective 
KPP). 
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4 

All  data,  that  will  be  exchanged  or  has  the 
potential  to  be  exchanged,  will  be  tagged  lAW  the 
current  JTA  standard  for  tagged  data  items 
(XML),  COE  Level  6  (Threshold,  KPP)  /  Level  8 
(Objective,  KPP). 

DELIVERY 

Survival  Information 
Dissemination 

4 

IDM  will  support  and  enable  dissemination  of 
survival  information  in  “n”  sec  (TBD)  or  less,  95% 
of  the  time  (Threshold,  KPP)  and  within  “n”  sec 
(TBD)  95%  of  the  time  (Objective,  KPP). 

Information  Integrity 

4 

IDM  will  ensure  that  information  integrity  will 
be  maintained  at  99.99%  (Threshold,  KPP)  and 
at  99.999%  (Objective,  KPP). 

Search  Driven 
Information 

4 

The  information  user  will  be  able  to  acquire 
needed  information  by  search  queries. 
Successful  searches  must  yield  85%  of  available 
needed  information,  with  no  more  than  20%  of 
the  total  received  being  irrelevant/unusable 
information  (waste)  or  failed  searches 
(Threshold,  KPP);  and  successful  searches 
must  yield  95%  of  available  needed  information, 
with  no  more  than  10%  of  the  total  received  being 
irrelevant/unusable  information  (waste)  or  failed 
searches  (Objective,  KPP). 

GIG  CRD:  Completeness,  Continuity,  Ambiguity,  Timeliness 


Table  10:  Excerpt  from  GIG  CRD  (U) 


FUNCTIONAL 

AREA 

CAPABILITY 

REQUIREMENT 

Interoperability 

Satisfy  Critical 
lER  Attributes 

Systems  shall  satisfy  all  critical  lER 
attributes  to  the  threshold  level  (Threshold, 
KPP)  and  satisfy  all  lER  attributes  to  the 
objective  level  (Objective,  KPP). 

Store 

Data 

Interoperability 

All  of  a  system’s  data  that  will  be 
exchanged,  or  has  the  potential  to  be 
exchanged,  shall  be  tagged  in  accordance 
with  the' JTA  standard  for  tagged  data  items 
(e.g..  Extensible  Markup  Language  [XML],  the 
current  JTA  standard),  and  tags  shall  be 
registered  in  accordance  with  the  DoD  XML 
Registry  and  Clearinghouse  policy  and 
implementation  plan  (Threshold,  KPP). 
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FUNCTIONAL 

AREA 

CAPABILITY 

REQUIREMENT 

Transport 

Quality  of 
Service 

Transport  systems  shall  provide  QoS 
capabilities  that  ensure  that  information 
identified  as  priority  is  delivered  ahead  of 
regular  traffic  99%  of  the  time  (Threshold, 
KPP)  and  99.9%  of  the  time  (Objective, 

KPP). 

Information 

Integrity 

Systems  shall  maintain  and  guarantee 
during  transport  the  integrity  of  all  information 
elements  exchanged  throughout  the  GIG  to 
enable  user  confidence:  information  integrity 
shall  be  99.99  %  (Threshold,  KPP)  and 

99.999  %  (Objective,  KPP). 

Transport 
Element  Status 

All  transport  elements  (e.g.,  switches, 
routers,  etc.)  shall  be  capable  of  providing 
status  changes  to  network  management 
devices  by  means  of  an  automated  capability 
in  near  real  time  99%  (Threshold,  KPP)  and 
99.9%  (Objective,  KPP)  of  the  time. 

Secure  Voice 
Interoperability 

Strategic  and  tactical  secure  voice 
systems  shall  be  interoperable,  with  a  99% 
(Threshold,  KPP)  and  99.9%  (Objective, 

KPP)  call  throughput  success  rate. 

Network 

Management 

Network  Status 

Systems  shall  have  an  automated  NM 
capability  to  obtain  status  of  networks  and 
associated  assets  in  near  real  time  99% 
(Threshold,  KPP)  and  99.9%  (Objective, 

KPP)  of  the  time. 

IDM 

Search  Driven 
Information 

Systems  shall  have  an  IDM  capability  to 
acquire  needed  information  by  search 
queries,  with  successful  searches  yielding 

85%  of  available,  needed  information  based 
on  the  user  query  and  with  no  more  than  20% 
being  irrelevant/unusable  (waste)  or  failed 
searches  (Threshold,  KPP);  and  yielding 

95%  of  available,  needed  information  and  no 
more  than  10%  being  irrelevant/unusable 
(waste)  or  failed  searches  (Objective,  KPP). 
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FUNCTIONAL 

AREA 

CAPABILITY 

REQUIREMENT 

Survival 

Information 

Dissemination 

Systems  shall  have  an  IDM  capability  that, 
utilizing  a  standard  schema,  lAW  the 
commanders’  dissemination  policies  and  user 
profiles,  will  support  the  means  for 
prioritization  of  information  flows  within  a 
theater,  using  theater  apportioned  resources, 
and  enable  dissemination  of  survival 
information  (limiting  survival  information  to 
less  than  12  kb)  within  the  time  frames  of  the 
matrix  portrayed  in  Figure  5,  95%  of  the  time 
(Threshold,  KPP)  and  0.5  seconds  95%  of 
the  time  (Objective,  KPP). 

Information 

Assurance 

Authentication/ 

Confidentiality/ 

Non-repudiation 

Systems  shall  meet  and  maintain  minimum  lA 
Defense  in  Depth  standards,  including 
certification  and  accreditation  lAW  the 

DITSCAP  process  (e.g.,  CJCSI  6510.01C, 

DoDI  5200.40)  (Threshold,  KPP). 

The  existence  of  these  CRDs  requires  several  near-term  actions.  First,  we  must 
understand  the  interaction  among  these  requirements  (tables  7-10)  and  ensure  we 
know  the  locations  of  gaps,  overlaps,  and  conflicts.  These  CRDs  are  the  product  of 
significant  intellectual  effort  -  the  next  step  is  to  ensure  they  are  consistent  and 
complementary,  and  to  show  how  they  interrelate  in  the  integrated  architecture. 

The  SIAP  SE  TF  is  assembling  relevant  requirements  into  the  SIAP  Integrated 
Architecture  where  a  consolidated  set  of  requirements  can  be  maintained  along  with  the 
traceability  necessary  to  identify  the  source.  Development  and  maintenance  of  a  single, 
common  set  of  requirements  is  needed  to  identify  and  document  the  interpretation  of 
requirement(s)  that  will  be  acknowledged  where  there  are  ambiguities  and/or  conflicts 
among  relevant  CRDs  and/or  ORDs.  More  importantly,  this  requirements  database  will 
serve  as  a  configuration  management  tool  for  the  requirements  set,  as  TAMD 
requirements  evolve  and  changes  are  made  in  response  to  geo-political  events  and 
technology  improvements. 

The  SIAP  SE  TF  also  draws  “requirements”  from  existing  service,  DoD,  and 
NATO  interface  standards  (e.g.,  OPSPEC  516.1,  MIL-STD-6016A,  and  STANAG  5516). 
These  “requirements”,  which  predate  the  JROC-validated  CRDs,  grew  from  a  system- 
oriented  attempt  to  characterize  a  desired  level  of  system  performance.  These  existing 
interface  standards  must  be  incorporated  into  the  SIAP  Integrated  Architecture  so  we 
can  better  understand  how  they  map  to  JROC-validated  capstone  requirements.  We 
discuss  specific  issue  with  the  interface  standards  in  Section  3.2 
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Requirements  levied  upon  the  Integrated  Air  Defense  System  will  consist  of 
general  requirements  and  participant  requirements.  General  requirements  specify  how 
the  IADS  perform  when  multiple  participants  are  interoperating.  Participant 
requirements  specify  how  a  system  shall  perform  to  be  certified  as  a  joint  participant 
and  ensure  that  all  participants  will  contribute  as  necessary  when  interoperating  to 
achieve  required  interoperability  as  stated  in  the  general  requirements. 

The  general  shape  of  the  requirement  that  seems  to  be  emerging  is  that  the 
SIAP  should  provide  ‘the  right  data  to  the  right  user  at  the  right  time'.  In  other  words, 
the  customers  for  the  SIAP  have  different  data  and  information  needs  that  they  want 
SIAP  to  provide  for  them,  depending  on  their  unit  type,  mission,  and  mission  phase. 

For  example,  a  fighter  has  different  SIAP  data  quality  needs  depending  on 
whether  It  is  on  a  Combat  Air  Patrol  (CAP)  mission,  has  been  assigned  a  mission 
against  an  aerospace  object,  or  is  in  a  highly  dynamic  many-on-many  air  combat 
engagement. 

Another  key  feature  of  the  objective  SIAP  is  that,  at  the  surveillance  level,  it 
should  provide  a  coherent  picture  to  various  platforms  viewing  the  same  aerospace 
objects.  That  is,  if  three  tactical  units  are  all  viewing  a  particular  object  via  the  same  or 
different  media,  such  as  Link  1 1 ,  Link  16,  and  CEC,  they  should  all  perceive  the  object 
as  the  same  object,  and  be  able  to  relate  it  to  a  common  track  number  and  set  of 
associated  characteristics.  This  is  the  generally  accepted  interpretation  of  the  terms 
‘single’  and  ‘common’  as  applied  to  SIAP  and  its  defining  references. 

On  the  other  hand,  one  of  the  often-cited  requirements  of  a  SIAP  is  ‘one-and-only 
one  track  number  per  object.'  There  are  times  when  this  implied  requirement  is 
unnecessary,  inefficient,  and  perhaps  unachievable,  and  could  work  to  the  detriment  of 
the  warfighters  the  SIAP  is  supposed  to  serve.  For  example.  Link  16  currently  permits 
tagging  a  flight  of  objects  moving  together  as  a  ‘group’  track,  with  a  strength  field 
providing  information  on  how  many  objects  that  track  report  represents.  If  every  object 
required  a  separate  track  number  in  the  surveillance  portion  of  Link  16,  the  efficiency  of 
track  grouping  would  be  lost,  and  fewer  objects  could  be  reported  in  the  same  amount 
of  capacity. 

But  Link  16  allows  those  group  tracks  to  be  broken  out  to  individual  tracks  on 
more  localized  subnets.  These  subnets  are  intended  to  be  used  by  ‘shooters’  for  whom 
a  single  track  per  target  is  a  necessity  for  target  sorting  and  engagement  coordination. 

So  it  is  possible,  and  more  efficient  in  Link  16  to  use  group  tracks,  where  the  fidelity  of 
individual  tracks  is  not  needed,  and  to  break  down  to  individual  tracks  where  such  detail 
is  necessary. 

Both  of  these  approaches  meet  the  needs  of  certain  users.  So  the  question,  for 
such  a  system  (and  for  the  SIAP  SE)  is,  if  the  platforms  who  need  the  breakout  down  to 
the  individual  target  have  it  (e.g.,  for  target  sorting,  engagement  coordination,  or 
whatever),  and  others  do  not,  do  we  say  that  the  specified  SIAP  requirement  is  met  or 
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not?  The  answers  to  such  questions  will  dictate  the  engineering  solutions,  which  must 
be  fielded  to  satisfy  SIAP  requirements. 

Earlier  it  was  noted  that  the  SIAP  itself  is  not  an  end;  it  is  a  means  to  achieve 
improved  warfighting  effectiveness.  In  any  finite  capacity  system  which  may  be  used  to 
help  build  the  SIAP,  especially  a  multi-functional  system  like  Link  16,  capacity  trade 
issues  arise  constantly,  and  the  engineering  of  the  best  system  (i.e.,  SIAP)  to  support 
the  customer  must  consider,  and  balance,  all  needs  (i.e.,  what  is  best  for  the  SIAP  may 
not  always  be  what  is  best  for  the  warfighter). 

Requirements,  by  their  nature,  are  not  concerned  with  existing  system  and 
technology  limitations.  This  creates  a  challenge,  in  that  specified  SIAP  requirements 
may  exceed  the  ability  of  existing  contributing  systems  to  meet  them.  If  such  is  the 
case,  then  the  SIAP  SE  has  some  choices.  First,  he  can  investigate  what  portion  of  the 
SIAP  requirements  can  reasonably  be  met  with  the  existing  systems,  including 
improvements  to,  and  enhancements  of  them.  Then  he  can  estimate  what  deltas  exist 
between  what  can  be  cost-effectively  achieved  toward  satisfaction  of  a  SIAP 
requirement  with  improvements  to  existing  systems,  and  develop  an  approach  for 
satisfying  those  deltas  with  new  systems.  Another  approach  might  be  to  define  the 
ultimate  system  that  will  meet  all  of  the  SIAP  requirements.  Due  to  the  perceived 
difficulty,  time  and  lack  of  resources  required  to  pursue  this  approach,  the  SIAP  SE  has 
been  directed  to  investigate  the  application  of  existing  (JDN)  systems  to  the  SIAP 
requirement.  In  either  case,  an  engineering  interpretation  of  the  SIAP  requirements  is 
needed. 

The  flow  of  requirements  from  JROC-validated  capstone  requirements  to 
individual  product  (equipment  and  computer  program)  specifications.  For  JROC- 
validated  capstone  requirements  to  be  realized,  it  is  necessary,  but  not  sufficient,  to 
derive  lower-level  requirements  and  to  make  these  requirements  a  contractual 
deliverable.  Within  the  aerospace  domain,  the  SIAP  SE  Task  Force  is  responsible  for 
the  translation:  the  way  in  which  this  translation  is  documented  and  communicated  is 
the  SIAP  component  of  the  System  and  Technical  views  of  the  TAMD  Integrated 
Architecture.  The  impact  of  this  process  on  a  particular  system  depends  on  the  phase 
of  the  system’s  lifecycle. 

3.1.2.  Products  and  Milestones 

The  objective  SIAP  Integrated  Architecture  will  be  focused  within  the  context  of 
JTAMD,  as  described  in  the  TAMD  2010  Operational  Concept  and  Joint  Vision  (JV) 
2010  and  the  integration  of  the  Joint  Data  Network  (JDN)  and  the  Joint  Composite 
Tracking  Network  (JCTN).  The  SIAP  SV  and  TV  products  will  include  all  relevant 
TAMD  primary  and  secondary  systems,  but  will  initially  focus  on  the  SIAP  SE  TF 
defined  Block  0  Core  Systems  and  the  2003  TAMD  Architecture  (Version  4).  The  deltas 
between  2003  and  the  objective  architecture  will  be  reflected  in  the  objective 
architecture  and  the  roadmap  that  results  in  growing  from  current  to  future  capabilities. 
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The  C4ISR  Architecture  Framework  2.0  describes  a  set  of  products  that 
comprise  an  integrated  architecture.  We  are  starting  with  that  prescribed  framework, 
and  tailoring  it  to  meet  our  specific  needs. 

Figure  1 1  shows  the  interrelationships  among  the  products  described  in  the 
C4ISR  Architecture  Framework  2.0.  The  three  main  components  of  the  Integrated 
Architecutre  are  operational,  system,  and  technical  views. 

a.  The  Operational  Views  define  notional  resources  required  to  perform  the 
activities  envisioned  from  the  operational  concept.  These  notional  resources 
will  be  described  by  association  operational  activities  and  the  needed 
information  exchanges  between  them.  A  logical  data  model  will  be  defined  to 
show  the  required  data  needed  to  perform  the  required  activities.  These  basic 
architectural  views  describe  in  detail  the  activities  to  be  performed,  the  need 
for  information  transfer  and  the  data  elements  required,  but  these  do  not 
define  actual  systems  and  system  interfaces. 

b.  The  Systems  Views  establish  the  relationship  of  the  notional  concepts  of  the 
operational  views  with  the  physical  systems  and  interfaces.  First,  the  notional 
resources  are  allocated  to  real  systems  and  system  elements.  These  systems 
are  then  further  broken  down  Into  the  functions  that  they  perform.  For 
continuity,  a  mapping  Is  done  back  to  the  activities  defined  on  the  Operational 
Views  to  ensure  that  all  required  activities  are  being  performed  by  system 
functions  within  system  elements.  Information  exchanges  between  systems 
are  defined  by  evaluating  the  connectivity  between  notional  resources  defined 
in  the  operation  architecture  views  and  the  required  data  for  the  systems. 
Actual  data  need  by  the  systems  to  accomplish  their  tasks  are  further  defined 
in  the  physical  data  model  which  is  derived  form  the  logical  data  model  in  the 
Operational  Views  and  the  data  needs  derived  from  the  system  function 
development. 

c.  The  Technical  Views  are  used  to  define  and  describe  the  implementation  of 
the  rules  and  standards  that  are  needed  to  implement  the  architecture  within 
the  systems  defined  in  the  system  architecture. 
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Figure  11.  C4ISR  Architecture  Framework  Reiationships 


The  architecture  products  will  be  produced  from  a  common  ubiquitous  database 
of  architectural  data  and  presented  in  several  forms:  functional/Unified  Modeling 
Language  (UML)  executable  models,  and  C4ISR  standard  information  views,  as  defined 
in  the  C4ISR  Architecture  Framework  2.0. 

The  primary  purpose  for  the  C4ISR  Architecture  Framework  views  will  be  in  the 
area  of  requirement  traceability  and  to  provide  an  acquisition  road  map.  The  primary 
purpose  of  the  Integrated  Architecture  Executable  Model  is  to  validate  behavior,  predict 
performance  and  update  the  SIAP  Integrated  Architecture. 

The  architecture  products  can  be  categorized  as  descriptions  of  the  physical, 
functional,  data,  performance,  evolutionary,  and  behavioral  characteristic  of  the  systems 
and  interfaces  which  contribute  to  the  SIAP  capability. 

The  SIAP  SE  TF  has  initially  focused  on  the  description  of  physical  systems  and 
their  interface,  starting  with  a  small  list  of  systems  and  then  expanding  to  greater 
numbers.  The  functional  description  is  focused  on  the  breadth  of  the  SIAP  capability 
first,  with  expansion  focused  on  detail  in  specific  functional  areas.  As  the  functional 
analysis  matures,  the  data  and  information  exchanges  will  be  defined  and  a  behavior 
analysis  will  be  conducted.  An  Executable  Model  will  be  developed  to  initially  exercise 
the  data  and  functional  flows  for  correctness  and  eventually  verify  performance.  The 
performance  and  evolutionary  description  are 

The  following  existing  and  pending  JTAMD  operational  views  will  be  reviewed  for 
requirements  and  SIAP  relevancy;  if  appropriate,  comments  will  be  provided: 

OV-1  High  Level  Operation  Concept  Graphic 
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OV-2  Notional  Resource  Connectivity  Description 
OV-3  Operational  Information  Exchange  Matrix 
OV-4  Command  Relationship  Chart 
OV-5  Activity  Model 
OV-7  Logical  Data  Model 

The  following  SIAP  products  will  be  produced  primarily  to  show  requirements 
traceability  and  traceability  to  the  JTAMD  OA  using  CASE  tools  to  validate  and  verify  all 
operational  requirements  will  be  met  by  the  SIAP  Integrated  Architecture: 

SV-4  Systems  Functionality  Description 

SV-5  Operational  Activity  to  System  Function  Traceability  Matrix 

SV-6  System  Information  Exchange  Matrix 

SV-7  Systems  Performance  Parameter  Matrix 

The  following  products  will  be  produced  primarily  to  assist  in  establishing  the 
acquisition  road  map  and  provide  guidance  for  improving  interoperability  among 
contributing  systems: 

SV-1  System  Interface  Description 
SV-2  Systems  Communication  Description 
SV-8  System  Evolution  Description 
SV-9  System  Technology  Forecast 
TV-1  Technical  Architecture  Profile 
TV-2  Standards  Technology  Forecast 

The  following  JTAMDO-produced  Operational  Views  and  SIAP  SE-produced 
System  Views  will  be  used  to  support  the  development  of  an  Integrated  Architecture 
Executable  Model: 

OV-6a  Operational  Rules  Model 

OV-6b  Operational  State  Transition  Description 

OV-6c  Operational  Event/Trace  Description 

SV-lOa  Systems  Rules  Model 

SV-1  Ob  Systems  State  Transition  Description 

SV-IOc  Systems  Event/Trace  Description 

SV-1 1  Physical  Data  Model 

Other  architecture  products  will  be  produced,  where  required,  to  provide 
additional  detail  for  the  above  architecture  products.  Figure  12  shows  a  summary  of 
SIAP  Integrated  Architecture  Milestones  and  shaded  areas  depict  active  development 
efforts. 
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Figure  12.  SIAP  Integrated  Architecture  Products 

Figure  13  shows  a  summary  of  SIAP  Integrated  Architecture  Milestones. 
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Figure  13.  SIAP  Integrated  Architecture  Milestones 


“Supported  by  the  JTAMD  process,  use  a  disciplined  system  engineering 
process  to  develop  the  system  and  technical  views  of  the  SIAP 
component  of  the  TAMD  integrated  architecture,  to  include  an  overall 
time-phased  development  and  deployment  schedule,  [SIAP  SE 
Charter] 

The  establishment  of  the  SIAP  Integrated  Architecture  began  in  July  2001  with 
the  establishment  of  the  purpose,  context,  scope  and  strategy  of  the  architecture  effort 
in  (AV-1 )  and  the  high  level  operational  concept  in  the  OV-1  and  OV-4  deliveries.  The 
SIAP  Integrated  Architecture  Strategy  is  based  on  the  philosophy  that  to  establish  a 
repository  of  architectural  artifacts  and  data  for  the  2010,  the  first  step  is  to  determine 
the  functional  contributors  to  the  SIAP  capability  that  exist  in  legacy  systems.  This  was 
accomplished  by  the  derivation  of  As-ls  SIAP  SVs/TVs  from  TAMD  (2003)  Architecture 
for  Joint  Force  Operations  (Ver4)  Dec  97,  with  updates  from  the  Services. 

Since  the  complete  number  of  contributing  systems  to  the  SIAP  capability  is  over 
100,  it  was  also  determined  to  start  with  systems  defined  as  critical  to  the  Block 
developments  and  then  expand.  The  first  development  of  the  SIAP  SV/TV  is  based  on 
the  12  “Core”  systems  as  defined  by  Block  0.  The  As-ls  architecture  should  be 
completed  by  April  2002. 

The  establishment  of  the  SIAP  Integrated  Architecture  must  begin  with  the 
operational  activities  required.  The  SIAP  operational  activities  and  the  interrelationships 
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required  to  satisfy  the  2010  will  be  determined  from  the  SIAP  2010  functional  thread  of 
the  JTAMD  2010  Operational  Architecture.  The  initial  establishment  of  the  SIAP  2010 
functional  thread  should  be  completed  by  January  2002.  By  establishing  the  SIAP  2010 
functional  thread  and  by  completing  the  description  of  the  As-ls  SIAP  Architecture,  the 
derivation  of  the  Draft  Objective  SIAP  SVs/TVs  will  be  completed  by  the  detailed 
comparison  of  the  functional  requirements  between  the  2010  and  2003  architectural 
products.  This  should  be  achieved  by  May  2002. 

Part  of  the  functional  description  of  the  SIAP  Integrated  Architecture  is  the 
description  of  the  rules  and  state  changes  governing  its  execution.  The  completion 
of  the  architecture  must  include  the  validation  of  the  As-ls  and  Objective  SIAP 
Architecture  Views  by  executing  the  functions  based  on  these  rules  and  state 
definitions  to  determine  if  the  architecture  performs  correctly.  The  validation  of  the 
As-ls  and  the  Objective  architectures  should  both  be  completed  by  July  2002. 

During  the  validation  process,  the  architectures  will  be  updated  for  a  final  delivery  in 
October  2002  and  a  final  briefing  to  the  JROC  on  the  SIAP  Integrated  Architecture 
by  December  2002. 

Figure  14  shows  the  original  path  in  the  development  of  a  SIAP  As-ls 
Architecture  in  the  context  of  Block  0  Systems  and  Block  0  improvements,  showing  a 
migration  strategy  with  the  Block  0  contribution. 


Figure  14.  SIAP  Integrated  Architecture  Near  Term  Block  0  Schedule 


This  initial  tasking  for  Block  0  established  an  architecture  pilot  to  refine  the  SIAP 
architecture  process.  The  resulting  architecture  will  further  be  used  to  support  the 
organized  implementation  of  the  Block  0  changes  among  the  Services.  The  scope  of 
the  architectural  products  was  limited  to  the  12  Block  0  “Core”  systems.  The  intention 
being  to  “eat  the  elephant  -  one  byte  at  a  time.”  The  expansion  of  the  As-ls  to 


encompass  the  more  complete  list  of  SIAP  contributing  systems  will  follow  in  larger  and 
larger  steps  as  defined  by  the  SIAP  SE  Control  Branch. 

3.1.2.1.  Functional  Baseline 

The  SIAP  will  facilitate  the  joint  forces’  ability  to  possess  adequate  awareness  of 
the  battlespace  and,  if  required,  engage  targets  at  the  edges  of  their  weapon 
engagement  envelopes.  While  this  all  sounds  good  in  theory,  in  practice,  there  must  be 
systems  that  can  perform  the  myriad  of  functions  required  that  span  the  kill  chain. 

These  functions  include  target  detection,  target  identification,  cueing,  and  target 
engagement.  While  these  systems  provide  organic  capabilities,  the  real  force  multiplier 
in  these  systems  is  when  they  are  netted  together  in  a  mutually  supportive  role,  and 
providing  a  battlespace  awareness  that  is  greater  than  the  sum  of  their  individual 
capabilities.  Indeed,  these  are  the  very  strengths  upon  which  the  JTAMD  2010 
capabilities  are  predicated;  e.g..  Combat  ID  (CID),  Integrated  Fire  Control  (IFC),  and 
Automated  Battle  Management  Aids  (ABMA).  In  addition,  capabilities  must  exist  to 
establish,  maintain  and  manage  these  networks  to  ensure  that  their  integrity  is 
maintained. 

As  already  indicated,  the  capabilities  required  by  the  TAMD  and  CID  CRDs,  such 
as  IFC  and  ABMA,  are  predicated  upon  the  existence  of  a  SIAP.  Consequently,  in  the 
course  of  pursuing  a  SIAP,  it  is  necessary  to  determine  the  functions  that  must  be 
performed,  the  information  required  to  perform  these  functions,  the  capabilities  that 
must  exist  to  provide  this  information,  the  systems  that  can  provide  these  capabilities, 
and  finally,  the  standards  that  are  associated  with  the  employment  of  these  systems. 

By  definition,  the  guiding  source  for  each  of  these  requirements  is  the  SIAP  Integrated 
Architecture.  It  is  through  the  individual  views  of  the  integrated  architecture  that  an 
objective  SIAP  capability  is  realized. 

While  SIAP  is  an  integral  part  of  the  JTAMD  mission  areas  and  provides  a 
greater  understanding  of  the  battlespace,  it  is  nonetheless  a  state  or  condition  that  must 
be  supported  by  technological  means.  These  means  exist  in  the  combination  of 
communication  networks  and  data  processing  used  by  the  services.  It  is  through  these 
networks  that  a  credible  air  picture  is  developed  (SIAP),  and  by  corollary,  an  improved 
understanding  of  the  battlespace  upon  which  warfighting  decisions  can  be  made. 

The  emerging  recommendations  regarding  the  contribution,  composition,  and 
functionality  of  the  Integrated  Air  Defense  System  are  addressed  in  two  aspects;  within 
the  context  of  the  SIAP  charter,  and  in  the  larger  context  of  the  JTAMD  multi-mission 
warfighting  environment.  While  they  are  being  addressed  in  two  separate  discussions, 
they  are,  in  fact,  inextricably  linked  since  architecturally  speaking,  the  SIAP  Integrated 
Architecture  is  a  part  of  the  larger  JTAMD  Integrated  Architecture.  And  it  is  through  the 
architecture  of  the  JTAMD  Family  of  Systems  (FoS)  that  the  SIAP  component  systems 
are  identified. 

The  TAMD  mission  area  is  composed  of  three  elements:  TAMD  C4I,  Offensive 
Counterair  Operations  (OCA),  and  Defensive  Counterair  Operations  (DCA). 
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•  TAMD  C4I  -  The  primary  functions  of  TAMD  C4I  are  to  provide  situational 
awareness  (SA),  enable  command  and  control,  and  facilitate  battle 
management  functions,  including  warning,  cueing,  and  enabling  engagements. 
The  TAMD  C4I  function  must  also  provide  applicable  command  authorities 
with  the  capability  to  plan,  monitor,  direct,  execute,  control,  and  report  TAMD 
operations. 

•  Offensive  Counterair  (OCA)  -  The  objective  of  OCA  operations  is  to  destroy, 
disrupt,  or  neutralize  enemy  aircraft,  missiles,  launch  platforms,  and  supporting 
infrastructure  and  systems.  Since  the  preferred  method  is  to  neutralize  targets 
as  close  to  the  source  as  possible,  preemptive  OCA  is  a  viable  option  and 
preferable  to  enemy  post-launch  OCA. 

•  Defensive  Counterair  (DCA)  -  The  objective  of  DCA  is  to  employ  all  defensive 
measures  available  to  detect,  identify,  intercept,  and  destroy  or  negate  enemy 
force  actions  near  friendly  forces  or  defended  areas.  DCA  consists  of  two 
elements:  passive  air  defense  and  active  air  defense. 

-  Active  Air  Defense  is  action  taken  directly  to  destroy  or  neutralize  the 
effectiveness  of  air  and  missile  threats  against  friendly  forces;  this  includes 
the  use  of  electronic  warfare. 

-  Passive  Air  Defense  is  action  other  than  active  air  defense,  taken  to 
minimize  hostile  air  and  missile  threats.  These  measures  include 
camouflage,  concealment,  and  deception  (CCD)  as  well  as  protective 
construction. 

To  satisfy  these  TAMD  mission  areas,  a  set  of  fundamental  warfighting 
capabilities  is  required.  These  supporting  capabilities,  identified  by  the  SIAP  SE  TF,  are 
categorized  as  Engagement  Operations  and  Non  Engagement  Operations. 

Engagement  operations  are  those  operations  that  pertain,  among  other  things,  to  the 
passing  of  time  critical  information  related  to  engagements,  multi-platform  weapon 
employment  coordination,  identification,  and  data  fusion.  Non-engagement  operations 
are  those  that  pertain  to  mission  planning,  intelligence  preparation  of  the  battlespace, 
and  management  and  control  of  the  quality  of  the  tactical  data  links.  These  two 
categories  of  warfighting  capabilities  provide  an  air  picture  that  is  lucid;  and  as  a 
corollary  not  only  facilitates  timely  detection  and/or  neutralization  of  air  and  missile 
threats,  but  also  prevent  fratricide.  It  should  be  at  least  implicitly  obvious  from  the 
above  that  the  system  functionality's  required  not  only  entail  the  ability  to  transmit  and 
receive  information  from  an  array  of  disparate  service  systems,  but  also  the  capability  to 
establish,  maintain  and  manage  these  networks  to  ensure  that  their  integrity  is 
maintained. 

As  the  component  of  joint  theater  air  and  missile  defense  that  has  been 
chartered  to  provide  the  “product  of  composite,  common,  continuous,  unambiguous 
tracks  of  airborne  objects  in  the  surveillance  area”,  these  SIAP  capabilities  present 
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themselves  collectively  as  the  sine  qua  non  of  the  JTAMD  mission  areas.  These 
capabilities  consists  of  the  following: 

•  Non  Engagement  Operations 

-  Intelligence  Preparation  of  the  Battlespace  (IPB) 

-  Joint  sensor  and  weapon  systems  planning 

-  Mission  planning 

-  Communication  services  planning 

•  Engagement  Operations 

-  Communication  services  operations 

-  Sensor  integration 

-  Sensor  gridlocking 

-  Data  fusion 

-  Identification 

-  JDN  and  JCTN  Integration  including  tactical  data  systems  and  links 

-  Engagement  coordination 

-  Multi-platform  weapon  system  integration 

This  listing  is  in  order  of  occurrence  as  the  SIAP  is  produced.  A  description  of  all 
these  capabilities  is  contained  in  Appendix  A. 

Due  to  historical  deficiencies,  the  SIAP  SE  TF  was  established  “to  identify  the 
most  effective  and  efficient  means  to  achieve  a  SIAP  that  satisfies  the  warfighter 
needs... .and  which  will  lead  to  measurable  improvements  in  warfighting  capability.”  It  is 
within  this  context  that  the  JDN  and  JCTN  networks  will  first  be  discussed. 

As  defined  in  section  3.1 ,  the  JDN  and  JCTN  provide  time  critical  information  in 
two  time  domains:  near  real-time,  and  real-time.  Information  in  near  real-time  is 
generally  used  to  provide  situational  awareness  (SA);  i.e.,  tracks  being  reported  can  be 
updated  every  5-10  seconds  and  do  not  need  to  be  updated  at  a  rate  comparable  to  a 
target  that  is  being  engaged.  Information  in  real-time,  on  the  other  hand,  is  used  to 
provide  fire  control  quality  information  on  tracks  that  pose  a  threat  and  must  be 
engaged.  If  and  when  required,  the  update  rate  of  this  information  must  be  of  sufficient 
frequency  to  support  a  weapon  engagement  evolution. 

In  any  given  battlespace,  there  are  tracks  that  can  be  updated  in  near  real-time, 
and  there  are  tracks  that  must  be  updated  in  real-time.  The  rate  at  which  they  are 
updated  is  based  upon  the  threat  that  they  are  perceived  to  pose  to  friendly  forces.  This 
however,  is  a  gross  simplification  of  the  network  issues  and,  in  order  to  understand  their 
relationship  to  providing  a  SIAP  in  the  context  of  the  Charter,  their  functionality  must  be 
understood. 

Regardless  of  the  rate  at  which  track  information  is  passed  around  in  a  network, 
the  track  information  must  not  only  be  easily  understood  but  useful.  In  addition,  the 
networks  as  well  as  their  information  must  be  managed  properly  such  that  the  right 
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information  is  passed  to  the  right  individual  at  the  right  time.  These  intrinsic 
functionalities  are  the  networks’  sole  reason  for  being. 

Now  that  the  required  capabilities  are  known,  the  JDN  and  JCTN  functionalities 
can  be  addressed  not  only  in  the  context  of  the  SIAP  Charter  but  also  in  the  context  of 
the  TAMD  multi-mission  warfighting  environment. 

We  recommend  that  the  functions  described  also  be  considered  for  inclusion  into 
the  next  version  of  the  JTDLMP. 

3.1. 2.2.  Allocated  Baseline 

The  SIAP  Acquisition  Roadmap  provides  the  overarching  migration  plan  for 
incrementally  integrating  the  SIAP  capability  into  the  JTAMD  Integrated  Architecture. 
The  Acquisition  Roadmap  will  be  derived  from  the  products  described  above  along  with 
Service  funding  and  scheduling  inputs.  The  Acquisition  Roadmap  will  include  all 
systems  and  capabilities  that  contribute  to  the  SIAP  and  will  balance  life  cycle  cost  and 
Joint  warfighting  capability.  The  Acquisition  Roadmap  builds  on  Block  0  implementation 
activities  by  further  defining  mid-term  and  far-term  block  upgrades  based  on  cost  and 
schedules  to  satisfy  operational  requirements  leading  to  the  objective  SIAP  capability. 
The  Acquisition  Roadmap  will  define  the  path  from  current  capabilities  through  the 
normative  baseline  to  the  objective  SIAP  capability  —  our  piece  of  the  TAMD  integrated 
architecture. 

To  ensure  cohesion  with  the  TAMD  Master  Plan,  the  SIAP  Acquisition  Roadmap 
is  being  developed  in  concert  with  the  Joint  Acquisition  Roadmap  (JAR)  and  the  Joint 
Capabilities  Roadmap  (JCR)  efforts. 


3.1.3.  Responsibilities 

Figure  15  shows  the  organizations  within  the  U.S.  Department  of  Defense  that 
are  key  stakeholders  in  the  development  of  the  SIAP  Integrated  Architecture.  The  SIAP 
Integrated  Architecture  is  a  decision-making  tool  and  intellectual  framework  that 
documents  the  results  of  the  collaborative  SIAP  system  engineering  process  that  will  be 
described  in  the  SIAP  System  Engineering  Management  Plan  (SEMP).  Each  Service, 
and  elements  of  the  Joint  Chiefs  of  Staff,  Office  of  the  Secretary  of  Defense,  and  United 
States  Joint  Forces  Command  are  participants  in  the  SIAP  system  engineering  and 
analysis  efforts.  These  efforts  develop  the  information  necessary  to  fuel  the  process 
that  builds  the  SIAP  Component  of  the  2010  TAMD  Integrated  Architecture.  The 
Services,  through  the  “virtual”  staff,  are  creators  (not  merely  reviewers)  of  the  elements 
of  the  SIAP  Integrated  Architecture.  Service  participation  also  includes  close 
collaboration  with  the  respective  Service  POC  members  of  the  Task  Force  Architecture 
Team.  The  SIAP  SE  TF  is  providing  funds  through  the  architecture  team  to  the 
Services  specifically  for  review  of  architecture  products,  but  the  Services  also  receive 
funds  for  participation  in  the  various  System  Engineering  Teams  (SETs)  and  other 
SIAP-related  Task  Force  activities. 
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Figure  15.  Service  and  Agency  Stakeholders 

Figure  16  shows  the  database  or  architectural  repository  which  supports  the 
SIAP  System  and  Technical  Views  (SV/TV)  and  is  established  by  deriving  information 
from  the  products  of  several  efforts  and  sources. 
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Data  is  traceable  to  the  requirements  established  in  the  TAMD,  CID,  IDM,  and 
GIG  CRDs.  These  requirements  are  interpreted  for  their  operational  context  by  the 
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JTAMD  2010  OA  effort  and  then  placed  into  a  physical  context  in  the  SIAP  SV/TV 
development. 

The  requirements  are  also  derived  in  the  JCR  to  JTAMD  functional  capabilities 
and  coordinated  for  acquisition  in  the  JAR.  The  input  from  the  JAR  is  then  combined 
with  other  SIAP  Acquisition  data  for  the  development  of  the  SIAP  Acquisition  Roadmap. 
The  information  in  the  SIAP  Acquisition  Roadmap  is  then  entered  into  the  SIAP  SV/TV 
and  related  to  specific  SIAP  system  functions  in  the  SIAP  Capability  Evolution 
Description  (SV-8). 

SIAP  performance  attributes  are  derived  from  the  CRDs  and  then  input  into  the 
SIAP  SV/TV  in  the  SIAP  Performance  Parameter  Matrix  (SV-7)  and  the  SIAP 
Information  Exchange  Matrix  (SV-6). 

Although  the  SIAP  Acquisition  Roadmap  and  SIAP  Analysis  and  Assessment 
efforts  have  primary  input  in  the  definition  so  SIAP  Capability  Evolution  and 
Performance,  respectfully,  their  impact  is  also  felt  in  the  physical  and  functional 
definitions  of  the  systems  and  all  other  aspects  of  the  SIAP  architecture  data  base. 

It  is  important  that  a  single  team  of  people  (JTAMDO  and  acquisition  personnel), 
led  by  a  single  architect,  develop  all  the  views  of  the  integrated  architecture  to  ensure  a 
smooth  transition  in  the  translation  of  operational  requirements  into  performance 
requirements  and  implementation. 


Recommendation:  Resolve  responsibility  for 
developing  and  maintaining  the  TAMD  Integrated 
Architecture  _ 


Recommendation:  Establish  a  Joint  system 
engineering  organization  to  continue  the  system 
engineering  work  necessary  to  translate  JROC  — 
validated  joint  warfighting  requirements  into  Service 
systems.  _ 


Recommendation:  Strengthen  the  linkage  between 
Advanced  Concept  Technology  Demonstrations  (ACTDs) 
and  the  requirements  process.  ACTDs  should  directly 
influence  requirements. _ 


3.1.4.  Approach 

The  most  significant  technical  issue  is  the  system  engineering  of  an  integrated 
JDN,  JCTN,  and  all  the  hosts  that  connect  to  these  networks.  This  is  formidable 
because  of  the  interdependencies  between  interacting  weapons,  surveillance  and  battle 
management  systems.  Such  interdependencies  demand  disciplined  system-of-systems 
engineering  approach,  including  an  integrated  architecture,  analysis,  engineering 
synthesis,  design,  testing,  and  certification.  It  also  requires  a  disciplined  acquisition 
strategy,  including  synchronization  among  the  interacting  components  that  must  all  be 
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in  place  and  working  together  at  the  same  time.  Both  of  these  considerations  go 
beyond  a  family-of-systems  approach  where  a  less  complex  federation  strategy  is 
expected. 


Figure  17  shows  the  SIAP  Integrated  Architecture  is  a  process  which  results  in 
architectural  products  that  are  iteratively  produced,  based  on  dialog  between  the  joint 
warfighter  (represented  by  JTAMDO)  and  the  architect.  The  beginning  and  continual 
update  of  the  process  is  focused  on  the  Service  system  owner.  The  operational 
requirements/behaviors  are  derived  from  the  TAMD  2003  Operational  Architecture  and 
the  JTAMD  2010  Integrated  Architecture.  Since  almost  all  of  the  systems,  which  will 
exist  in  2003,  will  also  exist  in  2010,  the  system  user  also  provides  a  description  of  the 
Service  Systems  both  functional  and  physical  to  establish  and  iterate  the  SIAP 
Component  Architecture  Repository.  The  resulting  architectural  products  are  reviewed 
and  executed  to  establish  the  architecture’s  behavior.  The  review  and  examination  of 
the  architecture  results  in  a  system  user/SlAP  Architect  interaction  and  continual  update 
and  refinement  of  the  architectural  repository. 
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Figure  17.  SIAP  Integrated  Architecture  Process 


The  SIAP  Integrated  Architecture  will  be  developed  to  support  Block  process 
upgrades  and  ultimately  result  in  an  "Objective”  Architecture.  The  SIAP  System  View 
(SV)  and  Technical  View  (TV)  products  will  include  relevant  primary  and  secondary 
Theater  Air  and  Missile  Defense  (TAMD)  systems  (from  the  TAMD  CRD);  be  based  on 
an  updated  2003  TAMD  Architecture  (Version  4)  (update  led  by  SIAP  SE  TF);  and, 
focus,  initially,  on  the  “Block  0”  ^systems  as  defined  by  the  SIAP  SE  process. ' 

The  “Objective”  SIAP  Integrated  Architecture  will  be  a  2010  architecture  that 
derives  from  the  JROC  validated  TAMD  and  CID  CRDs.  This  architecture  will  be 


^  Block  0  "core"  systems  are  Patriot  ICC,  FAAD  C2,  AMDPCS,  ACDS  Blk1  AEGIS  6  1  E-2C 
FA-1 8  C/D,  TAOM  (V)4,  E-3  AWACS,  MCE,  Rivet  Joint,  F-1 5  C/E, 
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derived  from  the  Operational  Views  (OVs)  of  the  2010  JTAMD  Integrated  Architecture 
and  the  As-ls  SIAP  SV  and  TV  products. 

The  differences  between  the  current  and  “objective"  architectures  will  be 
documented  in  the  SIAP  Integrated  Architecture. 

Figure  18  shows  a  six-stage  process  based  on  Structured  Analysis  for 
developing  C4ISR  architectures.  This  process  was  developed  by  Dr.  Alexander  H. 
Levis,  Professor,  System  Architectures  Laboratory,  C3I  Center,  George  Mason 
University  and  currently  the  Air  Force  Chief  Scientist.  The  output  of  the  process  is  a 
description  of  the  architecture  represented  as  Operational,  System  and  Technical  Views 
as  defined  by  the  C4ISR  Architecture  Framework  Version  2.0.  The  SIAP  SE  TF  is  using 
this  process  as  an  overarching  guide,  tailoring  it  where  appropriate,  to  develop  the 
System  and  Technical  Views  of  the  SIAP  Component  of  the  2010  JTAMD  Integrated 
Architecture. 


(see  ht^:/Ad]dng.g;miuedii) 

Figure  18.  Structured  Analysis  for  developing  C4ISR  architectures 


The  initial  products  of  the  Six-Stage  Process  were  reviewed  at  an  In-Process 
Review  (IPR)  held  on  1 0  Jul  01 .  These  initial  products  were:  1 )  the  All  Views  Overview 
and  Summary  Information  (AV-1),  2)  the  High-Level  Operational  Concept  Graphic  (OV- 
1),  and  3)  the  Command  Relationship  Chart  (OV-4).  AV-1  and  OV-1,  produced  during 
Phases  0, 1,  and  2  of  the  Process,  are  “stand-alone”  products  and  provide  a  baseline  to 
develop  the  remaining  System  and  Technical  Views  of  the  SIAP  Component 
Architecture.  AV-1  is  “standalone”  in  the  sense  that  it  not  only  is  part  of  the  Joint 
Theater  Air  and  Missile  Defense  (JTAMD)  AV-1  developed  by  JTAMDO  through  the 
JTAMD  Process,  but  is  also  a  stand-alone  document  to  describe  the  distinct  purpose, 
scope  and  context  of  the  SIAP  Integrated  Architecture.  OV-1  is  “standalone”  in  the 
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sense  that  it  not  only  augments  the  supporting  slides  of  the  JTAMD  OV-1,  but  is  also  a 
standalone  graphic  used  as  a  means  of  orienting  and  focusing  detailed  discussions,  at 
an  abstract  level,  of  the  operational  concept  of  SIAP. 

OV-4  was  provided  as  input  only  to  the  JTAMD  OV-4.  Comments  to  AV-1  and 
OV-1  received  at  the  IPR  were  incorporated  and  released  as  Version  2  on  15  Aug  01 
and  16  Aug  01,  respectively. 

At  the  29  Aug  01  IPR,  the  initial  draft  versions  of  the  following  System  Views 
were  reviewed:  1)  System  Interface  Description  (SV-1),  2)  System  Communications 
Description  (SV-2),  and  Systems  Functionality  Description  (SV-4).  These  System 
Views  are  work-in-progress  “As-ls”  SIAP  Integrated  Architecture  products  focused  on 
Block  0. 

Architecture  Development  Process:  The  Integrated  Architecture 

Views  will  be  developed  based  on  a  six  stage  process  (Figure  19)  developed  by 
Dr.  Alex  Levis.  The  stages  and  flow  of  these  stages  are  defined  below: 


Figure  19.  C4ISR  Architecture  Framework  Six  Stage  Process 


•  Stage  0:  Problem  Definition  and  Collection  of  Domain  Information 

•  Stage  1 :  Operational  Concept  and  Requirements 


•  stage  2:  Functions  and  Organizations 

•  Stage  3:  Activity  Model,  Logical  Data  Model,  Needlines,  System  Nodes, 
System  Elements  and  Functions,  and  Task  Allocation 

•  Stage  4:  Operational  Information  Elements  and  Exchanges,  System 
Functionality  Description,  Physical  Data  Model 

•  Stage  5:  System  Information  Elements  and  Exchanges,  LAN/  WANs,  System 
Interface  Description,  System  Performance 

The  document  the  SIAP  SE  Task  Force  is  going  to  use  to  detail  the  processes 
and  associated  products  required  to  support  the  engineering  of  a  SIAP  is  the  System 
Engineering  Management  Plan.  The  purpose  of  the  SEMP  is  to  support  engineering 
planning  and  control  for  systematic  engineering  and  integration  of  Joint  warfighting 
systems.  In  addition,  it  provides  an  integrating  framework  in  developing  the 
performance,  functional,  constraint  and  interface  requirements  for  SIAP,  from  top-level 
mission  area  requirements  through  system  products. 

While  SIAP-centric,  the  SEMP  is  based  upon  the  guidelines  of  IEEE  Std  1220- 
1998  and  documents  the  plan  to  conduct  the  fully  integrated  technical  effort  necessary 
to  satisfy  the  general  and  detailed  requirements  for  system  engineering  the  SIAP.  In 
essence,  the  SEMP  will  provide  a  standard  for  managing  the  development  of  the  SIAP 
through  a  disciplined  system  engineering  process  by  providing  a  uniform  framework  for 
controlling  all  SIAP  products  during  all  phases  of  development. 

3.1.5.  Resources 

We  will  allocate  resources  guiding  joint  engineering  efforts  to  create  the  SIAP 
portion  of  the  Integrated  Architecture.  The  Services  will  also  need  to  resource  their  own 
system  engineering  efforts  for  those  systems  that  contribute  to  or  compliment  the  SIAP 
lA.  Preliminary  assessments  put  the  Service  requirement  at  approximately  $5M  a  year, 
per  Service.  These  resources  must  be  allocated  soonest  if  we  are  going  to  meet  the 
December  2002  delivery  of  the  SIAP  portion  of  the  TAMD  Integrated  Architecture. 

3.2.  IDENTIFY  AND  RESOLVE  PROBLEMS  WITH  THE  JOINT  DATA  NETWORK 

(JDN) 

As  we  discussed  earlier,  the  SIAP  SE  TF  Charter  directs  us  to  pursue  two 
concurrent  efforts  to  improve  warfighting  capability  and  meet  the  JROC-validated  TAMD 
and  CID  capstone  requirements.  The  rigorous,  disciplined  system  engineering  process 
that  is  building  the  SIAP  Integrated  Architecture  is  following  a  traditional  top-down 
system  engineering  approach  tailored  from  IEEE  Std  1220-1998.  We  engaged  in  a 
companion  bottom-up  approach,  also  following  a  rigorous,  disciplined  system 
engineering  process.  These  concurrent  efforts  will  ensure  we  make  time-phased 
incremental  improvements  in  warfighting  capability  while  working  to  the  objective  SIAP 
capability  described  in  the  TAMD  Integrated  Architecture. 
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This  section  addresses,  in  the  context  of  the  TAMD  Integrated  Architecture, 
specific  materiel  and  materiel-related  deficiencies  that  degrade  joint  warfighting 
capability  today,  and  briefly  discusses  plans  to  resolve  these  deficiencies. 

3.2.1.  Objectives 

In  accordance  with  the  SIAP  SE  TF  Charter,  the  overarching  objective  of  the 
Task  Force  is  to  identify  incremental  improvements  that  will  lead  to  improved 
warfighting  capabilities  by  implementing  changes  to  equipment,  computer  programs, 
and  interface  standards.  The  SIAP  SE  TF  is  initially  concentrating  efforts  on 
resolving  long-standing  JDN  deficiencies,  starting  with  those  related  to  the 
implementation  of  Link-16. 

These  initial  efforts  will  identify,  prioritize,  and  recommend  fixes  and 
enhancements  to  deficient  processes  and  fielded  components  of  the  JDN,  applicable 
across  all  Services  and  leading  to  an  effective  long-term  objective  SIAP  capability. 
Related  to  this  objective,  the  SIAP  SE  TF  will  ensure  mission  success  within  constraints 
related  to  budget,  development  timelines  for  new  technologies  and  systems,  and  the 
realities  of  the  acquisition  process.  The  principal  technical  focus  will  be  the  ’ 
identification  and  correction  of  computer  program-coding  incompatibilities  that  exist  in 
fielded  weapon  systems.  Such  errors  prevent  cohesive,  complete  and  proper  JDN 
operations  and  do  not  comply  with  the  guiding  specification. 

The  SIAP  SE  TF  will  also  coordinate  the  identification,  exploration  and  crafting  of 
technical  enhancements  to  compliant  TDL  logic  that  permits  more  precise  warfighter 
communications.  All  current  functional  requirements  documents  remain  in  effect,  while 
the  technical  interoperability  specifications  are  revised  to  reflect  more  concise  common 
results.  All  of  these  activities  will  lead  to  refinement  of  the  processes  and  tools  that 
generate  less  than  optimum  TDL  operations.  It  will  also  result  in  tighter  MIL-STDs  to 
meet  Joint  critical  requirements  and  permit  less  interpretation  of  implementations  with 
more  predictable  and  consistent  results. 

The  most  timely  and  cost  effective  approach  to  implementing  these  near-term 
JDN  improvements  is  to  incrementally  employ  block  upgrades  consisting  of  logically 
related  fixes  or  enhancements  across  the  Services,  thereby  minimizing  the  amount  of 
modification,  testing  of  the  host  computer  programs  and  expenditure  of  resources.  This 
approach  incorporates  both  participation  in  the  JINTACCS/JTAMD  processes  and 
supports  the  on-going  analysis  of  the  Joint  Acquisition  Roadmap. 

Implementation  of  materiel  JDN  improvements  will  require  modification  to 
affected  host-system  equipment  and  computer  programs.  In  addition,  testing  and 
certification  will  be  required  following  implementation  of  any  modification.  Multiple  JDN 
improvements  may  impact  the  same  computer  programs  and  equipment  in  many 
Service  host  systems.  Therefore,  the  most  cost  effective  approach  to  implementing 
near-term  JDN  improvements  is  to  incrementally  employ  block  upgrades  consisting  of 
logically  related  fixes  or  enhancements  across  the  Services,  thereby  minimizing  the 
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amount  of  modification  and  testing  of  the  host  computer  programs.  The  block  upgrades 
will  be  synchronized  with  affected  Service  program  development  schedules  to 
determine  optimal  insertion  points. 

Block  upgrades  allow  early  implementation  of  improved  capability  while  retaining 
flexibility  to  insert  new  capabilities  or  technologies  in  the  future.  The  Block  approach  is 
an  expedient  method  of  improving  joint  capability  by  implementing  changes  to  existing 
TTP  and  systems,  while  remaining  an  integral  part  of  the  integrated  architecture.  For 
each  Block  upgrade,  the  Detailed  Block  Improvement  Plan  will  identify  the  specific 
changes  required  in  specific  systems  to  achieve  defined  improvements  to  the  SIAP 
capability.  An  incremental  approach  to  improving  the  JDN  will  balance  legacy  system 
enhancements  with  future  SIAP  development. 

The  incremental  Block  Process  is  initiated  to  address  SIAP  deficiencies  noted 
within  the  JDN.  These  deficiencies  are  identified  to  the  SIAP  SE  via  various  means.  The 
SIAP  SE  TF  inputs  the  data  into  the  Lessons  Learned  database  (LLDB)  and  organizes 
and  aligns  it  within  the  system  engineering  process.  This  data,  along  with  other  inputs, 
is  used  to  categorize  the  JDN  fixes  into  Blocks  that  can  be  system  engineered  as  a 
group  and  implemented  across  the  Services.  The  SIAP  SE  will  develop  Task 
Statements  for  engineering  activities  to  be  addressed  by  a  Block  Team. 

The  Block  Team  will  be  chaired  by  a  member  of  the  SIAP  SE  Task  Force  Core 
Engineering  Team  and  will  have  representatives  from  the  Services,  MDA,  and 
JTAMDO.  The  Block  Teams  will  establish  a  joint,  collaborative  systems  engineering 
approach  to  provide  oversight  of  the  JDN  fix  process.  The  Block  Teams  will  organize 
and  manage  Engineering  Analyses,  Cost  Benefit  Analyses,  and  Plan  of  Action  & 
Milestone  (POA&M)  recommendations  focused  on  improvements  to  the  JDN.  The 
POA&M  document  is  a  means  of  documenting  all  of  the  above  and  outlining  the  tasks, 
schedules,  milestones,  dependencies,  management  requirements,  and  deliverables  for 
the  Block  initiative.  It  is  the  Block  Team  that  provides  the  orchestration  of  the  entire 
Block  initiative  and  ensures  the  POA&M  is  executable  and  on  track  to  reaching  the 
deliverables. 

The  TF  will  then  collect  data  and  conduct  the  detailed  analysis  required  to 
perform  a  cost  benefit  analysis  of  the  engineering  solutions  for  the  deficiencies  within 
the  particular  Block.  The  results  are  then  coordinated  with  the  service 
SYSCOM/PEO/PM,  JFCOM,  and  the  JTAMD/JINTACCS  processes.  The  Block  Team 
will  prepare  the  SIAP  SE’s  recommendation  to  the  JROC  by  presenting  the  system, 
product,  or  process  specifications:  preparing  supporting  rationale  based  on  testing  and 
analysis:  and  providing  the  acquisition  impacts  anticipated  in  fielding  these 
improvements  in  a  Decision  Support  Binder  (DSB)  format.  In  addition,  information 
concerning  capability  assessments  of  fielded  systems  will  be  provided  for  use  in  the 
SIAP  SE  TF  Capabilities  and  Limitations  documentation. 
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3.2.2.  Products  and  Milestones 


The  primary  product  developed  by  the  incremental  Block  system  engineering 
teams  will  be  a  set  of  engineering  recommendations  in  the  form  of  Interface  Change 
Proposals  (ICPs)  and/or  Engineering  Change  Proposals  (ECPs)  communicated  through 
the  DSB  and  briefings  to  the  JROC,  SAEs,  and  Service  Program  Offices.  The 
secondary  products  include  lessons  learned,  prioritized  improvement  lists,  and  M&S 
tools  supporting  evaluation  and  prediction  of  SIAP  functionality. 

The  Block  1  products  will  include  a  set  of  specific  engineering  recommendations 
in  the  form  of  Interface  Change  Proposals  (ICPs)  and  Engineering  Change  Proposals 
(ECPs)  with  supporting  rationale. 

Doctrine,  Organization,  Training,  Materiel,  Leadership,  Personnel,  and 
Facilities  (DOTMLPF)  Issues 

In  the  past,  resolution  of  JDN  problems  and  deficiencies  has  focused  primarily  on 
materiel  solutions  to  resolve  problems.  As  a  result  of  recent  real  world  lessons  learned 
and  analysis  of  test  and  evaluation  results,  it  has  become  evident  that  in  many  cases 
materiel  deficiencies  are  only  a  subset  of  the  true  problem,  not  necessarily  the  primary 
cause.  Doctrinal,  organizational,  training,  and  personnel  issues/problems  have  been 
directly  linked  to  many  of  the  problems  that  occur  during  JDN  operations.  The 
DOTMLPF  approach  to  issue  resolution  is  a  holistic  process  that  keys  on  addressing 
issues  across  a  broader  spectrum  (DOTMLPF)  resulting  in  a  improved  solution  set  for 
the  warfighter.  To  facilitate  implementation  of  DOTMLPF  solutions  identified  by  CINCs, 
Services,  and  Agencies  (C/S/A),  CJCSI  3180.01  (draft)  has  been  developed  to  define  a 
process  that  allows  DOTMLPF  change  proposals  to  be  addressed  and  resolved  at  the 
Joint  level. 

We  have  a  detailed  Work  Breakdown  Structure  (WBS)  that  will  support  the 
development  of  these  products  on  the  tentative  schedule  described  in  Figure  20. 
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Figure  20.  Integrated  Plan 


3.2.3.  Responsibi'iities 
JTAMD  Process 

From  the  SIAP  perspective,  the  Joint  Theater  Air  and  Missile  Defense  (JTAMD) 
process  is  a  formalized  process  designed  to  define  requirements  for  improving  theater 
air  warfare  capability.  The  JTAMD  process  impacts  potential  SIAP  customers,  by 
developing  the  SIAP  requirements.  As  noted  earlier,  these  SIAP  requirements  may  be 
met  using  current  systems,  or  by  developing  new  systems.  It  is  the  SIAP  SB’s 
responsibility  to  recommend  to  the  JROC  the  most  cost-effective  combination  of 
changes  to  existing  systems  and  fielding  of  new  systems  to  meet  the  JTAMD  developed 
requirements. 

JINTACCS  Process 

The  Joint  interoperability  of  Tactical  Command  and  Control  Systems 
(JINTACCS)  process  is  the  current  process  the  Services  use  to  introduce,  analyze,  and 
approve  changes  to  many  of  the  SIAP  contributing  systems  (i.e.,  TDLs,  which  are  the 
main  components  of  the  JDN).  The  formation  of  the  SIAP  SB  TF  by  the  leaders  of  the 
DoD,  and  current  interest  in  network  centric  warfare,  appear  to  be,  at  their  core,  a 
recognition  that  our  past  processes  have  been  too  platform  centric  (i.e.,  we  have 
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sometimes  let  the  interests  of  a  specific  platform  take  precedence  over  the  interests  of 
the  whole  group).  In  this  context,  it  would  appear  that  one  of  the  goals  of  the  creation  of 
the  SIAP  SE  TF  is  to  help  elevate  the  interests  of  the  whole,  and  to  provide  the 
engineering  rigor  which  shows,  where  true,  that  properly  balancing  the  individual 
platform  and  network  interests,  the  whole  can  be  made  more  effective  than  the  sum  of 
its  parts.  The  SIAP  SE  will  attempt  to  define  specific  warfighting  benefits,  which  can  be 
measured  as  part  of  the  justification  process  for  SIAP  recommended  changes. 

CINCUSJFCOM;  Demand  that  required  TDL  communications,  data  sharing  and 
command  messages  are  executed  in  an  unambiguous  fashion.  Enforce  TDL 
Certification  requirements.  Support  the  JICO  Support  System  training  to  generate 
expert  authorities  in  network  designs  and  weapon  system  limitations.  Place  TDL 
interoperability  high  on  the  CINC  Integrated  Priority  List  to  ensure  proper  funding  of 
these  critical  theater  assets.  Be  a  vocal  TDL  advocate  and  learn  to  articulate  the 
operational  benefits  of  an  unambiguous  TDL. 

Services:  Consider  Joint  TDL  interoperability  requirements  as  a  Prime  Directive  when 
designing  new  weapon  systems  or  enhancing  fielded  ones.  Include  sister  Service 
representatives  in  the  capabilities  and  design  decision  phases  of  TDL  changes. 

Exercise  concise  Configuration  Management  of  all  TDL  changes  using  TULIP  or  a 
similar  approved  construct.  Organize  and  operate  Service  TDL  design  activities  to 
directly  involve  both  requirements  and  resourcing  agencies  from  the  earliest  stages. 
Ensure  proper  attention  to  Service  commitment,  implementation  and  fielding  schedules. 
Plan  and  POM  for  appropriate  funds  so  they  are  available  to  synchronize  the  fielding  of 
mutually  supporting  Joint  warfighting  capabilities.  Ensure  TDL  operators  are  provided  a 
strong  voice  in  demonstrating  deficiencies,  lessons  learned  and  suggested 
enhancements.  Provide  Jointly-chartered  Service  representatives  as  subject  matter 
experts  to  the  Single  Integrated  Air  Picture  System  Engineer  Task  Force  to  help 
produce  the  best  possible  solution  to  Joint  TDL  requirements. 

Agencies:  Foster  a  mindset  within  the  DoD  which  emphasizes  and  rewards  the 
alignment  of  Service  resources  to  meet  Joint  warfighting  requirements  above  that  of 
conflicting  Service-specific  desires.  Generate  synchronized  and  mutually  supporting 
policies  to  guide  the  DoD.  Set  and  enforce  gateways,  thresholds  and  authorities  to 
monitor  and  affect  progress  of  new  initiatives.  Establish  a  robust  multi-level 
interoperability  certification  process  to  document  and  guarantee  interface  compliance 
with  Joint  Architectures  and  CRDs  to  demonstrate  expected  operational  results. 
Reinforce  the  high  priority  of  Joint  and  NATO  interoperability  relative  to  requirements 
refinement,  weapon  systems  enhancements,  budgeting  and  human  resources. 

SIAP:  Identify  the  most  effective  and  efficient  means  to  achieve  a  SIAP  that  satisfies 
the  warfighters  needs.  The  SIAP  SE  will  satisfy  this  mission  by  initially  implementing  an 
incremental  block  improvement  process  supported  by  a  disciplined  system  engineering 
process. 
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JITC:  Support  thorough  independent  operational  test  and  evaluation/assessment  of  C4I 
acquisitions:  identify  interoperability  deficiencies;  conduct  rigorous  interoperability 
testing,  evaluation  and  certification;  and  provide  technical  assistance  as  required. 

JIEO:  Provide  engineering  and  interoperability  support. 

MDA:  Develop  and  manage  programs  for  overall  system  integration  to  achieve 
interoperability  among  systems,  to  include  architecture,  forTAMD  and  cruise  missile 
options. 


3.2.4.  Approach 

The  Task  Force  includes  a  “Lessons  Learned”  Integrated  Product  Team  (IPT) 
that  is  charged  with  researching  the  results  as  well  as  working  with  Service  System  and 
Interoperability  Tests  and  Exercises  to  continue  to  identify  lessons  learned  and 
document  a  complete  and  consistent  set  of  problem  reports.  The  Block  upgrades  will 
begin  by  pulling  from  this  database  (refer  to  section  2.3)  and  apply  the  system 
engineering  disciplined  approach  (IEEE  Std  1220)  as  detailed  in  the  SEMP. 

For  the  purpose  of  considering  possible  actions  that  might  be  recommended,  the 
Task  Force  recognizes  that  some  of  the  possible  solutions  are  simply  to  fix  problems 
that  have  been  identified  in  system  acceptance  testing  and/or  in  interoperability  tests 
and/or  exercises.  However,  to  stop  at  that  point  would  be  negligent  of  the  problems 
forecast  to  be  emerging.  For  instance,  as  BM/C3I  systems  become  more  advanced  and 
more  complex  functionality  is  desired  in  order  to  provide  commanders  with  more  or 
better  information,  additional  bandwidth  will  be  needed.  In  fact,  more  bandwidth  is 
needed  to  support  the  concept  of  a  Joint  Composite  Tracking  Network  to  communicate 
sensor  data,  support  the  fusion  algorithm,  and  disseminate  the  resulting  information.  In 
addition,  the  static  nature  of  current  tactical  digital  information  links  needs  to  be  matured 
to  a  dynamic  network  concept  where  communications  transmissions  are  not  constrained 
to  static  time-slots.  While  current  concepts  talk  of  time-slot  reallocation  (TSR),  it  is 
envisioned  that  dynamic  network  management  would  reduce  many  manpower  and 
personnel  resource  requirements  while  also  leveraging  automation  to  enable  more 
mature  concepts  that  are  also  more  reliable  and  robust. 

The  definition  of  problems  and  issues  that  must  be  fixed  is  a  continual  process 
addressing  all  components  of  DOTMLPF  (Doctrine,  Organization,  Training,  Materiel, 
Logistics,  Personnel,  and  Facilities).  Objective  solutions  to  SIAP,  and  possibly  the 
larger  FlOP  problem,  are  needed.  The  plan  to  solve  these  problems  is  divided  into  two 
basic  areas:  (1)  Systems  and  technical  architecture  issues  including  interoperability, 
integration,  synchronization,  infrastructure  and  life  cycle  components  of  the  JDN  and 
JCTN  system  solution  and  (2)  Operational  issues  of  Tactics,  Techniques,  and 
Procedures  (TTPs). 

Implementation  flaws  are  the  responsibility  of  the  acquisition  programs  that 
produce  the  equipment  and  computer  programs.  We  do  not  track  these  flaws.  We  are 
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concerned  about  the  warfighting  implications  of  these  flaws,  particularly  because  the 
number  of  these  flaws  across  the  IADS  runs  into  the  thousands.  While  many  of  these 
flaws  have  “work  arounds”,  the  sheer  number  contributes  to  confusion  and  operator 
overload. 

The  Department  of  Defense  has  been  struggling  with  developing  insight  into  the 
impact  of  these  issues.  The  Joint  Distributed  Engineering  Plant  (JDEP)  was  developed 
to  help  identify  these  implementation  flaws. 


Recommendation:  Establish  an  objective  priority 
assignment  scheme  for  implementation  of  recommended 
fixes  to  flaws  discovered  during  JDEP  testing 


We  do  not  have  sufficient  resources  to  permit  the  kind  of  robust  testing  that  will 
be  necessary  to  fully  characterize  performance.  Shortfalls  in  simulation/stimulation 
capability  and  severe  shortfalls  with  site  availability  limit  utility  in  understanding 
“structural”  issues.  Lack  of  ability  to  modify  computer  programs  makes  JDEP  unsuitable 
as  a  development  tool.  JDEP  is,  however,  a  useful  tool  but  it  must  be  used  in  concert 
with  other  tools  and  disciplines. 

The  “structural”  issues  are  the  heart  of  the  system  engineering  task.  We  took  the 
“stmptural”  entries  from  the  Lessons-Learned  Database.  We  will  use  our  Block  1  effort 
to  “pilot”  the  ability  to  do  joint  system  engineering  to  work  on  specific  issues.  This  work 
will  help  build  the  team.  As  a  result  of  this  process,  the  C/S/A  will  gain  a  collaborative 
SE  environment. 


3.3.  SIAP  BLOCK  1 

As  stated  in  the  SIAP  Implementation  Plan,  the  purpose  of  Block  0  was  to 
exercise  the  system  engineering  process  and  to  help  the  Services  adopt  the  tools  and 
build  the  foundation  for  a  collaborative  engineering  environment.  The  Block  0  process 
initiated  an  approach  for  making  system  engineering  decisions.  As  a  result  of  this 
process,  we  built  interpersonal  relationships,  honed  communication  skills,  and  identified 
areas  of  work.  As  a  pilot,  the  Block  0  system  engineering  process  provided  the  team 
with  many  lessons  from  a  variety  of  aspects  including  technical,  programmatic,  financial, 
and  administrative. 

Block  1  will  incorporate  lessons  learned  as  a  result  of  our  Block  0  experience  to 
ensure  improvements  are  made  as  we  build  the  SIAP  System  Engineering  process. 

The  approach  outlined  below  incorporates  those  lessons  as  it  shapes  the  content  of  the 
next  block  upgrade. 

Block  1  WIPT.  The  Block  1  WIPT  will  be  comprised  of  the  Block  1  Manager,  the 
SIAP  SE  Branch  Heads,  two  Service/MDA  Points  of  Contact  from  each  Service/MDA 
(one  person  will  be  responsible  for  handling  acquisition  issues  and  one  person  will  be 
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responsible  for  handling  resource  issues),  and  a  representative  from  JTAMDO  and 
CINCUSJFCOM.  The  Block  1  WIPT  will  be  charged  with  developing  the  system 
engineering  recommendation  for  each  Block  1  candidate  issue  (which  are  identified  in 
follow-on  paragraphs).  These  joint  collaborative  engineering  working  groups  (one  for 
each  issue  -  however,  some  working  groups  may  be  tasked  with  working  several 
related  issues)  will  be  led  by  a  SIAP  SE  Task  Force  member  and  be  comprised  of 
subject  matter  experts  from  the  Services.  The  working  groups  will  apply  an  established 
Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  system  engineering  process 
(requirements  analysis,  functional  analysis,  synthesis  alternatives,  and  cost  benefit 
analysis)  to  determine  the  most  beneficial  way  to  provide  an  improvement  in  warfighting 
capability. 

Services.  As  defined  in  the  SIAP  SE  TF  charter,  the  Services  will: 

“Participate  in  SIAP  SE-led  engineering  efforts  to  improve  the  performance  of 
systems,  which  contribute  to  developing  a  SIAP.  Assist  in  characterization  of 
issues,  including  problem  and  root  cause  identification,  determination  of 
operational  impact,  and  identification  of  temporary  near-term  fixes  or  changes  in 
tactics,  techniques,  and  procedures  that  can  alleviate  symptoms  while  a  longer- 
term  solution  is  engineered.  Conduct  engineering  and  system  analysis/system 
trades  for  the  determination  of  cost  effective  SIAP  upgrades  to  legacy  systems.” 

Specifically,  provide  the  subject  matter  experts  that  will  form  the  Block  1  WIPT 
and  support  the  collaborative  joint  system  engineering  efforts  necessary  to  develop 
engineering  recommendations  for  improving  warfighting  capability. 


3.4.  DEFINE  THE  ELEMENTS  OF  THE  JOINT  COMPOSITE  TRACKING  NETWORK 

(JCTN) 

In  this  section  we  discuss  the  plan  to  provide  a  joint  composite  tracking  capability 
in  response  to  JROC-validated  warfighting  requirements  (e.g.,  TAMD,  CID,  IDM,  and 
GIG  CRDs). 

The  "JCTN"  envisioned  by  previous  studies  and  other  efforts  [JCTN  Phase  I] 
[JCTN  Phase  II]  [JCTN  Technical  Requirements  Document]  [JCTN/JDN  Gateway 
Technical  Requirements  Document]  [Min-Mix  Study]  embodied  a  broad  list  of  functions. 
While  the  functionality  ascribed  to  the  “JCTN”  centered  on  composite  tracking,  it  also 
included  functionality  that  study/effort  participants  believed  must  be  implemented  in  a 
common  way  across  network  participants,  if  performance  goals  (these  studies  and 
efforts  pre-date  the  TAMD,  CID,  IDM,  and  GiG  Capstone  Requirements  Documents) 
were  to  be  met. 

Common  implementation  of  functionality  is  a  necessary  condition  to  achieve 
consistency  across  participants,  so  the  intent  behind  allocating  functionality  to  the 
“JCTN”  is  justified  and  correct.  This  allocation,  however,  must  be  done  with  great  care 
and  must  be  done  in  close  coordination  with  the  systems  with  which  such  a  capability 
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must  integrate.  Moving  functionality  arbitrarily  and  without  associated  action  within  the 
“host”  will  cause  conflicts  that  manifest  themselves  as  problems  within  individual 
warfighting  units,  which  will  propagate  problems  across  the  networks. 


3.4.1.  Objectives 

The  objective  of  this  effort  is  to  meet  the  specific  requirements  contained  in  the 
JROC-validated  TAMD,  CID,  IDM,  and  GIG  CRDs. 

Multi-sensor  composite  tracking  of  air  vehicles  among  dispersed  sensor 
platforms  was  motivated  initially  by  needs  (1 )  to  avoid  gaps  in  tracks  caused  by  natural 
phenomena  such  are  obstructed  line  of  sight,  Doppler  notch,  and  multi-path  fading;  (2) 
to  increase  effective  measurement  rate  against  maneuvering  objects  with  sensors  that 
individually  are  constrained  to  low  update  rates;  (3)  to  overcome  countermeasures 
against  radars  such  as  mainlobe  jamming  to  deny  range  measurements  and/or 
signature  reduction;  and  (4)  to  resolve  closely  spaced  objects  through  viewing  angle 
diversity.  With  development  and  considerable  experience  has  come  appreciation  of 
composite  tracking  capabilities  as  an  (5)  effective  counter  against  low  observable  (LO) 
threats  and  (6)  a  communications  capability  common  computer  program,  and 
associated  infrastructure  in  which  participants  share  a  very  consistent,  kinematically 
accurate  air  picture.  Air  vehicle  composite  tracking  provides  significant  advantages  in 
all  these  areas  over  single-sensor  tracking  and  reporting  responsibility  (R2)  type 
networks. 

Integrated  fire  control  (IFC)  against  air  vehicles  has  been  motivated  primarily  by 
the  need  (7)  to  perform  beyond-line-of-sight  engagements,  particularly  against  low  flying 
threats;  (8)  to  overcome  characteristics  of  fire  control  radars  that  significantly  constrain 
engagement  space,  such  as  azimuth  field-of-regard  limits;  and  (9)  to  enable  advanced 
engagement  tactics,  such  as  launching  while  employing  emissions  control  (EMCOM). 

All  of  these  increase  battle  space,  depth  of  fire,  and  weapons  effectiveness. 

The  JCTN  concept  combines  both  multi-sensor,  multi-platform  composite 
tracking  and  IFC  to  gain  the  benefits  listed  above.  As  a  data  association,  processing, 
and  communications  resource  for  common  tactical  algorithms,  it  also  can  support  (10) 
composite  classification  and  identification  of  targets,  (1 1)  engagement  coordination  for 
both  single-unit  and  IFC  type  engagements,  and  (12)  network-wide  dynamic  sensor 
support  coordination  to  exploit  fully  the  detection,  non-cooperate  target  recognition 
(NCTR),  and  electronic  counter-countermeasures  capabilities  of  participating  sensors, 
as  well  as  to  balance  and  reduce  sensor  resource  loading. 

When  combined  with  effective  “gateway"  functionality  to/from  Link  16  NPG  7  (and 
hence  to  the  entire  JDN  via  other  gateways),  the  JCTN  can  (13)  be  the  primary  tracking 
engine  for  creation  and  maintenance  of  a  theater-wide  air  vehicle  SIAP  and  (14)  allow 
JDN  networks  to  operate  more  efficiently  by  concentrating  R2,  nearly  eliminating  R2 
contention  traffic,  and  providing  very  accurate  tracks  with  which  JDN-only  units  can 
correlate  their  local  tracks. 
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Some  of  the  benefits  listed  above  can  be  achieved  by  separate,  narrowly  focused 
material  solutions,  for  example,  a  JTIDS/MIDS-based  subnet  to  perform  IFC  among  a 
small  set  of  sensor  and  weapons  types.  While  some  of  these  narrowly  focussed 
solutions  can  be  justified  on  the  basis  of  immediate  need,  they  are  costly  to  support  as 
long-term  solutions.  The  JCTN  concept,  including  related  gateway  functionality, 
subsumes  such  narrowly  focused  solutions  with  a  broadly  capable,  widely  used  material 
solution  based  on  common  software  running  in  standard  processing  environments 
implementing  best-of-breed  algorithms  and  exploiting  multiple  communication 
technologies. 

3.4.2.  Products  and  Milestones 

Before  the  products  and  milestones  can  be  addressed,  there  are  several 
characteristics  relating  to  the  “Joint  Composite  Tracking  Network”  that  must  be 
acknowledged.  While  the  term  Joint  Composite  Tracking  Network  (JCTN)  is  used 
frequently,  there  is  no  widely  accepted  definition  for  this  network.  Rather  than  debate 
the  definition,  the  Task  Force  began  an  architectural  development  effort  that  will  define 
the  required  functionality.  We  also  expect  the  architecture  to  support  analysis  of 
functional  gaps,  overlaps,  duplicative  efforts  and  conflicts. 

Technically,  JCTN  is  conceptual.  JCTN  is  not  a  distinct  capability  that  functions 
separately  from  other  networks.  The  SIAP  integrated  architecture  will  translate 
requirements  and  define/allocate  functionality  to  weapon  systems  that  can  be  mapped 
back  to  network  concepts.  This  allocated  functionality,  when  it  exists,  will  be  an  integral 
part  of  a  larger  battlespace  awareness  capability  that  is  greater  than  the  sum  of 
individual  capabilities.  It  is  this  integrated  capability  that  will  be  required  to  satisfy  the 
TAMD  2010  Master  Plan,  e.g.,  CID,  IFC,  ABMA.  As  such,  the  products  and  milestones 
specifically  articulated  in  3.1 .2.  refer,  ipso  facto  to  the  integrated  capabilities  that  will  be 
required.  In  this  context,  those  characteristics  considered  to  be  within  the  JCTN  domain 
are  part  and  parcel  of  the  SIAP  “objective”  architectural  products.  Consequently,  the 
Block  improvements,  in  conjunction  with  the  architectural  products,  provide  a  time 
phased  and  cogent  set  of  recommendations  to  ultimately  achieve  those  TAMD  2010 
capabilities,  of  which  JCTN  is  a  part. 

3.4.3.  Responsibilities 

As  we  discussed  in  Section  2,  we  are  working  with  JTAMDO  to  develop  a  series 
of  Common  Reference  Scenarios  that  will  define  the  operational  environment  for  SIAP 
system  engineering  and  assessment  efforts.  The  analytic  process,  also  discussed  in 
section  2,  is  structured  to  evaluate  candidate  approaches  to  meet  JROC-validated  CRD 
requirements.  We  will  use  these  tools  to  develop  recommended  solutions  to 
demonstrated  warfighting  capability  shortfalls. 
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3.4.4.  Approach 


As  we  discussed  in  Section  3.1,  our  approach  is  to  derive  composite  tracking 
requirements  through  our  work  to  complete  the  Block  1  effort  and  the  functional 
decomposition  in  the  SIAP  integrated  architecture. 

In  order  to  satisfy  the  fundamental  JTAMD  2010  Operational  Elements,  there  is  a 
need  for  a  joint,  composite  tracking  network  (sic)  capability.  While  some  services  are 
progressing  to  that  end,  such  as  the  Navy’s  Cooperative  Engagement  Capability  (CEC), 
additional  analysis  and  exploration  is  still  required  to  ensure  that  the  resulting 
capabilities  developed  for  JTAMD  2010  satisfy  the  joint  force  requirements  and  is  not 
service-centric.  We  intend  to  collaborate  with  the  CEC  development  and  exploit  those 
technologies  that  are  relevant  to  a  joint  composite  tracking  capability. 

3.4.5.  Resources 


We  cannot  yet  estimate  the  resources  necessary  to  engineer  a  Joint  Composite 
Tracking  Network.  We  do  have  a  significant  body  of  work  from  previous  efforts  that  will 
probably  reduce  the  resources  required  to  do  the  engineering  required. 
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4.  SUMMARY  AND  CONCLUSIONS 


The  SIAP  SE  Task  Force  has  made  a  good  start.  This  is  unprecedented  work  to 
solve  long-standing  problems  in  joint  interoperability.  Consistent,  strong  support  from 
leadership  is  required  to  make  meaningful  progress.  We  cannot  continue  historically 
ineffective  processes  and  expect  the  outcome  to  be  different.  Our  previous  reliance  on 
Service  good  will  has  not  worked  sufficiently  to  solve  our  shortfalls.  Interoperability 
KPP’s  must  be  a  threshold,  not  an  objective.  Support  from  Service  SMEs  is  tantamount 
to  providing  thoroughly  vetted  recommendations. 

Block  0  served  as  an  exercise  in  team  building,  identified  our  infrastructure 
shortfalls,  and  unearthed  various  areas  where  we  can  make  improvements  in  processes 
and  products. 

Block  1  is  striving  to  make  systems  better  now  while  the  architecture  is  on  the 
path  to  an  objective  SIAP.  The  architectural  products  will  assist  in  the  decision-making 
process.  Sharing  information  and  progress  with  the  variety  of  stakeholders  within  the 
Department  will  help  us  meet  expectations. 

Specific  challenges  include: 

•  Building  a  common  definition  of  joint  interoperability  and  its  priority  -  how  does  it 
compete  with  other  requirements? 

•  Quantifying  the  benefits  of  joint  system  engineering-system  engineering  doesn't, 
by  itself,  win  wars  (no  flame,  detonation),  so  it  is  very  difficult  to  compete  with 
high  visibility  programs 

•  Linking  architecture  to  individual  weapon  systems. 

•  This  is  a  legacy  world.  Whatever  we  do  must  account  for  the  large  number  of 
existing  systems,  many  of  which  are  difficult  to  change. 

•  Maintaining  Service  accountability  for  system  implementation  and  certification  in 
accordance  with  the  integrated  architecture.  SIAP  SE  can  be  effective  if  properly 
supported.  We’ll  know  if  success  is  possible  when  Block  0  changes  are 
implemented. 

•  Synchronizing  Service-directed  acquisition  strategies  across  a  complex  family  of 
systems  -  a  key  to  realizing  ensemble  performance. 

•  Translating  between  system  requirements  and  capabilities  of  the  ensemble. 

ORDs  aren’t  written  for  missions  -  KPPs  are  typically  written  too  vaguely.  Spiral 
development,  performance  based  specifications  and  capabilities  versus  threat- 
based  engineering  have  also  clouded  the  issues. 

•  Specifications  and  standards  are  insufficient  to  achieve  the  required  level  of 
performance  unless  interfaces  are  well  characterized  and  tightly  controlled. 

•  Leveraging  advanced  technology.  Advanced  Concept  Technology 
Demonstrations  spur  on  more  appetite  than  DoD  can  consume  and  transition. 

How  do  we  leverage  existing  investments  in  technology  and  transition  these  into 
joint  warfighting  capabilities? 
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•  Focusing  similar  Service  and  Joint  experiments  and  initiatives  synergistically 
instead  of  each  competing  over  scarce  DoD  resources. 

•  Managing  external  relationships  (JTIC,  DISA,  JIEO,  etc.) 

•  Working  with  NATO  -  can’t  go  it  alone. 

•  Accommodating  current  personnel  processes.  It’s  difficult  to  train  people  before 
they  rotate  to  a  new  assignment.  Tough  to  get  something  done  in  a  2  year  tour  - 
must  have  continuity  and  constancy  of  purpose.  Civilian  and  contractor  decision¬ 
makers  stick  around  -  the  military  doesn’t. 

The  SIAP  isn’t  real  until  it  shows  up  on  the  battlefield,  and  it  can’t  show  up  on  the 
battlefield  until  the  following  is  done: 

•  Requirements  well  articulated 

•  Engineering  changes  developed 

•  IV&V/Testing/Certification  determined  for  joint  implementation 

•  Contracting  strategies  established. 

As  the  Task  Force  establishes  the  engineering  foundation  for  others  to  build  on, 
other  critical  elements  need  to  accompany  this  Joint  engineering  initiative: 

•  JTAMDO  must  complete  the  Operational  Views  of  the  SIAP  Integrated 
Architecture 

•  DOT&E  should  institutionalize  the  SIAP  metrics  as  the  assessment  measures 
for  characterizing  SIAP  performance  and  to  endorse  the  end-to-end  analysis 
process 

•  And  ultimately  USD  (AT&L)  should  assign  an  activity  to  budget  for,  update, 
and  manage  the  configuration  of  the  SIAP  component  of  the  TAMD  Integrated 
Architecture. 

This  SIAP  Integrated  Architecture  should  be  the  basis  for  how  DoD  must  develop 
its  JDN/JCTN  roadmap.  The  Task  Force  made  progress  in  building  initial  segments 
supporting  this  architecture  and  we’ve  mapped  out  the  architectural  discipline  needed  to 
trace  requirements  to  materiel  alternatives  that  will  define  that  roadmap.  It  is  this 
disciplined  approach  that  will  help  DoD  clarify  requirements,  identify  deficiencies  in  the 
JDN  and  define  the  elements  of  the  JCTN  concept.  And,  by  using  integrated  fire  control 
as  a  key  engineering  driver  for  future  capability,  we  expect  the  plan  we’ve  laid  out  in  this 
report  will  provide  a  highly  accurate  DoD  network  linking  CRD  requirements  to  specific 
materiel  alternatives. 


88 


APPENDIX  A 


I  Mb.  UINUtK  S>fcUheb.  I  AMY  Ub  utl-  t-INSb. 

3O!0  DErENSE  PENTAGON 
WASHINGTON,  DC  30301-3010 

mm 


MBMOR.WDUM  FOR  SINGLE  INTEGRATED  AIR  PICTURE  ACQUISITION  EXECUTIVE 

SUBJECT:  Single  Integrated  Air  Picture  (SIAP)  System  Engineering  (SB)  Task  Force  -  Report 
on  Progress,  Plans  and  Recommendations 

The  USD  (AT&L),  VCJCS,  and  DoD  Chief  Information  Officer  chartered  the  SIAP  SE 
Task  Force  in  October  2000  and  pul  in  place  the  nmnagetnent  process  that  will,  among  otiier  tasks, 
define  an  integrated  amhitecture  to  provide  a  Single  Integrated  Air  Picture  (SIAP)  for  joint  forces. 
The  Joint  Theater  Air  and  Missile  Defense  (JTAMD)  Executive  Committee  (EXCOM)  met  in 
November  2000  and  reviewed  plans  to  develop  the  broader  opemtionol  and  systems  architecture 

views  needed  to  define  the  SIAP.  I  request  a  report  to  the  JTAMD  EXCOM  on  the  Task  Force’s 
progress  and  plans  to  define  the  SIAP  integrated  architecture,  identify  and  resolve  problems  with 

tho  Joint  Data  Network  (JDN),  and  define  the  clctMcnts  of  the  Joint  Composite  Tmukiiig  Network 

(JCTN).  The  report  should  be  presented  to  the  JTAMD  EXCOM  by  September  30. 2001,  through 
the  JTAMD  Overarching  Integrated  Product  Team,  and  offered  to  the  Joint  Requirements 
Ovcislglit  Council  before  It  is  presented  to  the  EXCOM.  Ensure  that  the  report  includes: 

•  Emerging  recommendations  regarding  the  contribution,  composition,  and  functionality  of  the 
JUN  and  JCTN  networks  within  the  context  of  the  SIAP  SE  Task  Force  Charter,  and  within 
the  broader  context  of  the  multi-mission  vrarflghting  environment. 

•  A  plan  to  develop  a  JDN  and  JCTN  roadmap,  including  an  implementation  strategy  that 
addresses  interoperabiHiy,  integration,  and  synchronization.  As  the  SIAP  SE  Task  Force 
develops  this  plan,  they  should  woik  closely  with  the  Joint  Theater  Air  and  Missile  Defense 
Organization  (JTAMDO),  Ballistic  Missile  Defense  OiganLzation  (BMDO),  and  Joint  Forces 
Command  (JFCOM)  to  ensure  tliat  it  properly  considers  aspects  of  Doctrine,  Organization, 

TT^imns^  MatpiripL  T -ftaf Facilities!  (ODTMLPF). 

•  Resources  and  schedule  needed  by  the  SIAP  SE  Task  Force  to  estimate  the  costs  of 
engineering  solutions  for  JDN/JCTN  across  the  JTAMD  mission  area. 

•  Status  of  personnel  and  funding  for  the  SIAP  SE  Task  Force,  identifying  shortfalls  or  issues. 

•  Key  issues  and  concerns  of  the  SIAP  System  Engineer. 
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MEMORA^^D(J^^  FOR  SECRETARIBS  OF  THE  MILITARY  DEPARTlViENTS 

CHIEFS  OF  MILITARY  SERVICES 
ASSISTANT  SECRETARY  OF  DEFENSE  (C3I) 

DIRECTOR,  BALLISnC  MISSILE  DEFENSE  ORGANIZATION 


SUBJECT:  Management  of  'Dicater  Air  a«I  Missile  Defense  Activities 


This  rncmonindum  sets  forth  the  management  structure  to  be  used  by  the  Department  of 
Defense  in  providing  the  Joint  Force  Commanders  improved  capability  to  defend  against  air  and 
missile  tlireats.  A  key  objective  of  this  structoe  is  to  cfFcctivcIy  and  efficiently  integrate 
requirements  and  acquisition  activities  for  Theater  Air  and  Missile  Defense  (TAMD)  efforts. 

The  management  changes  described  herein  ■will  not  alter  Service  or  Agency 
responsibilities  for  program  execution  and  resource  rtjanagemenL  Ratiier,  these  changes  will 
enhance  coordination  between  lire  requirements  and  acquisition  communities,  focus  requirements 
generation  and  planning  activities,  furnish  systerns-of-sy steins  eagtnccring  at  the  architecture 
level,  and  provide  for  integrated  oversight  by  tivc  Department’s  senior  leaders.  A  key  product  of 
this  effort  will  be  a  TAMD  Master  Plan  diat  includes  requirements  and  acquisition  road  maps. 
The  Director  for  Force  Structure,  Resources  and  Assessment  (DJ-5?)  is  responsible  for  producing 
the  operational  concepts  and  requirements  section  of  the  TAMD  Master  Plan.  The  Director, 
Ballistic  Missile  Defense  Organization  (BhfDO)  is  responsible  for  producing  the  acquisition 
section  of  the  TAMD  Master  Plan. 

The  Sccrsliity  of  Defense  and  the  Chairman  of  the  Joint  Chiefs  of  Sta.ffare  establishing 
tinder  the  Director  for  Force  Structure^  Resources,  and  Assessment  {DJ-8),  as  a  Cltainnaii’s 
coDtroUed  aciivily,  a  Jouit  Theater  Air  and  Missile  Defeuse  Organization  (JTAMDO)  to  define 
the  required  system  interoperabilities  and  opctatjortal  architecciircs,  and  to  validate  tl^e 
developing  joint  theater  air  and  missile  defense  capabilities  through  bodi  sunuiation  arjd 
technology  demonstrations-  1lie  JT/\MDO  shaJ]  coordinate  with  die  warfightLug  CiNCs  and 
Militaiy  Semecsto  develop  joint  mi-ss  ion  capstone  rcquiTcmenly,  a  joint  mission  architecture, 
and  a  joint  capabilities  roadmap,  Ihese  efforts  wUi  be  documented  in  the  rcquireinetsts  section  of 
the  IVl-MD  Master  Plan  for  validation  by. the  Joint  Requirement?  Oversight.  Council  (JROC).  All 
responslbUJtics  and  funciionr?  previously  assigned  by  thn  A^ssistant  Secretary  of  Defemis  (C3i)  u> 
the  Hxecutive  A.gcnt;  for  Theater  AJ.r  Defemsc  BMCdl  will  be  transfened  to  the  JTAJ/roO. 


BN'IDO  shall  assume  the  role  cf  Intcgralion  Systems  Ardutect  for  thctaier  air  a:id  missile 
ccicoscs.  Woffang  jointly  with  JT.AMIXJ  and  the  Sepdetrs,  DMiyj  will  uranslate  the  J'TAiVfDO- 
dcvclopcd  operational  arrhiteciare  irno  systems  archhec’ures,  perform  systems  engineering  at  the 
ajciiUccaue  level,  plan  d^d  ensure  integrated  Ccsling  of  defense  a/chiceeh.iies,  tne  lead  progreun 
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acqubirioa  activitics-BMDO  also  sliall  work  closely  svithvService  and  Joint  piogranroffices  to 
develop  a  jointacqutairioQroadsTiap,  Hiese  efforts  will  be  documented  in  the  acquisition  section 
of  the  TAf'dD  Master  Plan  for  validatioa  by  the  Service  and.  Bali  isdc  Missile  Defense  Acquisition 
Executives.  Any  maaagcnicat  changes  required  for  BMDO  to  ftilfiil  this  role  will  not  impact 
Service-uniquC'i^SponsEbflitics.  ' 

Tto  flilfill  :«aetr  respoDsibilities.  JTAMDO  and  BMDO  shall  work  closely  osi  ng  m 
Intc^tcd  Product  Team  (jPT)  Approach,  Only  together  —  aod  with  the  C1HCS4  Services,  .OSD, 
and  Joint  Staff  -  do  they  have  the  systems  cogineenag  and  opcrationsl  expertise  needed  to  define 
eperatioDal  concepts  and  systems  requirements,  produce  an  effective  fnmily-of^systems 
architecture,  ensure  its  proper  test  and  evaluation,  and  integrate  it  with  the  other  elcinests  of  an 
effective,  wide-area  air  and  missile  defense  against  emerging  threats.  To  this  cnd,  .the  Director 
JTANfDO'andthe  BMDO  director  forTAJdD  shall co^chair  an  Jategration  Integrated  Product 
Team  (IIPT)  to  oversee  coordination  of  TAMD  requirEments  and  acquisition  acrivicy.  This  IIPT 
wiO  form  working-lcvcUPTs  as  needed,  in  such  areas  as  operational  concepts,  roquirements. 
weapons,  BMC4I,  iotegmted  testing.  mcdcliDg  and  simulation,,  hardware  and  software 
commonality,  navigation  warfare,  combat  identification,  and  red  teaming.  The  Director,  Strategic 
and  Tactical  Systems  and  the  Dtrccior  for  Force  S  tnicturc,  Resourees  and  Assessment  (DJ-8). 

Will  co-chair  an  Ovenurchiag  ipTfOfPT)  forTAMD,  on  which  die  Depucy  Assistant  Secretaiy  of 
Defense  {C3I  Acquisition)  will  play  a  prominent  role.  BMDO  shall  recommend  to  die  OiPT 
appropriate  assignment  of  acquisition  rcsponstbilities  for  the  family-of-systcms.  clemcnt-to- 
demetil,  and  individual  etement  design  and  cnginecriRg  dutws^iis'  OlPT  will  suppotf  rc'riew  of 
GMD  activities  by  an  Executive  eornmitteeco-chaifed  by  the  undersigned.  The  Director, 

JTAMDO  will  advise  the  Executive  Committee  dlrectlyon  the  degree  to  which  the  TAMD 
Master  Plan  meets  the  Depadsnent’s  Ob] eefives  for:  Joint  Tlieater  Air  and  Missile  Defease. 

The.Dircctor  for  Force  Stmeture,  Eesourecs  li^vAsscsIimertt  (DM)  shall  provide  to. 
USDfA&T)  a»d  the  VCJCSby  November  22. 1996.:  a  plan  to  esmblish  the  JTAMDO,  The 
Director,: BMDO  shallpcovido  toUSDCAa^T):  and  by  Noyemher  22,  1996,  a  plan.to 

integrate  TAMD  systems  engfoeering  and  technical  Activities.  These  plans  will  idcotiiy  needed 
agreements,  describe  responsibnitics  and  a  dctailed  fnsnagetpecifi  approach,  recoriimeiid  changes  to 
charters,  present  the- start-up  schedule,  .and  propose  any  adjustments  in  petsonr5e,l  or.  resources 
needed  to  carry  out  this  wtofk- 

.  Mamtaiaiag  an  effective  and  robust  theater  defense  agaiiiSi  the  emergiag  air  tnd  missiie 
threat  is  a  challccgtog  . 'problem.  With  die  faest  efforls  of  all  e|c«eftts  of  the  .DcpartfOCtlt,  working 
together  in  this  integrated  manner,  wc  can  .meet  this  ehalleage. 


JOSEPH  W.  RAI.STON 
Vice  Chairman 
Joist  Chiefs  of  Staff 
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DEFINITIONS 


FORCE  OPERATIONS 

Intelligence  Preparation  of  the  Battlespace; 

Intelligence  preparation  of  the  Battlespace  (IPB)  integrates  data  from  numerous 
intelligence  systems  to  provide  the  warfighter  with  the  best  possible  situation  awareness 
regarding  battlespace  environment,  terrain  and  enemy  locations,  capabilities  and  plans. 
This  information  enables  making  the  best  possible  use  of  blue  assets  by  supporting  the 
mission  planning  functionality,  (source:  JTAMD  CRD  Mar  2001) 

Joint  Sensor  &  Weapon  Systems  Planning; 

Modeling  of  Joint  TAMD  sensors  and  weapon  systems  to  determine  sensor  and 
weapon  system  coverage/performance  against  the  anticipated  Enemy  order  of  Battle 
(EOB),  and  Enemy  Courses  of  Action  (ECOAs).  Automated  display  of  expected  sensor 
performance  throughout  the  theater  as  a  function  of  blue  force  laydown  and  threat 
characteristics  (e.g.,  RCS,  trajectory,  and  altitude  of  anticipated  threat  aerospace 
vehicles).  Automated  display  of  weapon  system  performance  throughout  the  theater  as 
a  function  of  blue  force  laydown  and  aerospace  threat  characteristics. 

Mission  Planning: 

Utilizing  guidance  and  direction  from  Joint  Task  Force  and  Component 
Commanders,  the  Friendly  Order  of  Battle  (FOB),  products  of  the  IPB  process  (e.g.  the 
EOB,  and  ECOA)  and  products  of  "Joint  Sensor  &  Weapon  System  Planning", 
determine  optimal  blue  force  lay-down  and  alternate  courses  of  action  in  defense 
against  the  TAMD  threat. 

Communication  Services  Planning 

Communication  planning  services  will  consist  of  decision  aids  to  support 
development  and  management  of  communication  architectures/configurations  and.  real¬ 
time  capabilities  to  support  the  monitoring  and  control  of  communication  operations. 
Communication  planning  capabilities  will  include,  but  not  be  limited  to; 

■  Modeling  of  communication  performance  to  support  sensor  and  weapon  system 
planning  and  blue  force  laydowns 

■  Tools  to  develop  and  assess  network  architectures  and  network  configurations 

Real  Time  communications  planning  services  will  include  but  not  be  limited  to 
monitoring  and  control  of: 

■  Communication  system  configurations  and  status 

■  Connectivity  between  TAMD  units 

■  Bandwidth  utilization  and  allocations  (e.g.,  TSR, Link-22  SNC) 

■  Data  latencies  between  units 

ENGAGEMENT  OPERATIONS 

Establish  and  Maintain  Track  Files 

1.  Communication  Services 

In  accordance  with  guidance  provided  by  JICO,  initiate  and  maintain 
communication  connectivity  between  TAMD  units  and  distribute  data  to  support  SIAP 
and  TAMD  operations.  Distribution  of  data  will  include  but  not  be  limited  to  real-time 
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and  near  real-time  data  necessary  to:  1)  develop  and  maintain  the  SIAP;  2)  support  C2 
and  weapons  coordination;  and  3),  support  integrated  fire  control  engagements  based 
by  local  and  remote  sensors.  Joint  networking  capabilities  will  include  JCTN  and  JDN 
for  the  exchange  of  real-time  and  near-real  time  data,  respectively.  Specific  functions  to 
be  performed  will  include,  but  not  be  limited  to: 

■  Network  initiation  and  management 

■  JDN  &  JCTN  message  generation 

■  Message  flow  control  and  routing,  (e.g.  L1 1/1 6/22  protocols) 

■  Message  transmission  and  reception 

■  Joint  Range  Extension  (JRE) 

■  Automatic  translation  and  forwarding  between  components  of  the  JDN 
(e.g.,  Link-16  to  Link-11,  Link-22  to  Link-16) 

2.  Local  and  Remote  Sensor  Integration 

TAMD  sensors  will  provide  an  interface  to  the  JCTN.  Sensor  inputs  to  the  JCTN  will 
include  local  and  remote  sensor  measurement  data  in  support  of  composite  tracking, 
target  characterization,  identification,  discrimination,  sensor  coordination,  and  weapon 
system  control.  Outputs  to  the  sensors  from  JCTN  will  include  information  necessary  to 
task  the  sensor  to  support  sensor  and  weapon  system  coordination  and  control  of  both 
local  platform  and  IFC  engagements.  There  will  be  no  interface  between  the  JDN  and 
sensors.  Data  products  derived  from  local  sensors  will  be  interfaced  with  the  JDN  by  the 
host  tactical  data  system. 

3.  Sensor  Registration  &  Gridlock 

For  all  local  TAMD  sensors  contributing  to  the  SIAP  and  supporting  TAMD 
operations,  continuously  and  automatically  calculate  sensor  bias  corrections  as 
pertinent  to  each  particular  sensor  type  (e.g.,  range  measurement  offset  bias,  azimuth 
biases,  elevation  biases).  Sensor  registration  should  also  produce  an  estimate  of 
residual  bias  error  covariance.  Corrections  from  the  sensor  registration  will  be  applied 
to  remove  biases  from  sensor  measurements. 

Considering  all  TAMD  units  connected  via  the  Joint  Networks  continuously  and 
automatically  calculate  and  correct  navigational  errors  with  sufficient  accuracy  to 
support  the  spectrum  of  TAMD  operations,  including  SIAP  generation,  TBMD  target 
discrimination,  and  IFC  engagements.  Sensor  gridlock  will  consider  available 
navigational  sources  (e.g.,  GPS,  INS)  and  local  and  remote  sensor  data  to  align  local 
and  remote  sensor  data  to  a  Jointly  agreed  upon  common  coordinate  reference  frame. 

4.  Common  Nav/Time 

Maintain  navigation  solutions,  consisting  of  platform  position,  velocity,  and 
platform  attitude,  in  a  Jointly  agreed  upon,  absolute  reference  frame  that  can  be 
translated  to  the  WGS-84  latitude/longitude/altitude  and  earth-centered  earth-fixed 
Cartesian  frames.  Also,  maintain  common  time  reference  to  universal  coordinated  time 
(UTC)  as  established  by  the  U.S.  Naval  Observatory.  Inputs  from  the  U.S.  Global 
Position  System  (GPS),  as  well  as  site  surveys,  gravity  measurements,  gyro- 
compassing,  and  other  techniques,  will  be  used. 
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5.  Data  Fusion  and  Tracking 

Data  fusion  and  tracking  will  accept  locally  derived  and  remotely  provided  TAMD 
sensor  measurement  and  track  state  data  and  associate  tracks  and  sensor 
measurements  with  locaily  processed  tracks  and  sensor  measurements.  When  sensor 
measurement  data  is  available  (i.e.,  JCTN)  the  associated  local  and  remote  sensor  data 
will  be  fused  and  integrated  to  form  a  single  composite  track  state  (e.g.  track  position 
and  veiocity  state  vectors)  and  track  characterization  (e.g.  IFF  codes,  ESM  attributes). 
Fused  sensor  measurement  data  will  also  be  used  to  support  cued  acquisitions,  new 
track  initiation,  and  guidance  control  for  weapons  systems.  When  local  and  remote 
track  state  data  is  availabie  (e.g.  JDN),  integration  of  track  states  wilt  be  performed, 
which  includes  track-to-track  correlation. 

6.  Identification 

Track  identification  will  include  target  classification,  identification  and 
discrimination  capabilities.  Target  classification  will  use  fused  sensor  information  to 
derive  and  resolve  differences  in  track  types  (e.g.  ASM,  TBMD,  Aircraft)  and  platform 
types  (e.g.  F16).  Target  identification  will  determine  each  tracks  ID  in  accordance  with 
Link  16  primary  ID  taxonomy  (unknown,  assumed  friend,  friend,  neutral,  etc)  and 
resolve  differences  between  units.  Track  discrimination  will  use  fused  TAMD  sensor 
information  to  resolve  and  identify  TBM  objects  within  a  TBM  cluster.  JDN  and  JCTN 
will  not  perform  the  Combat  ID  (CID)  function;  however,  will  provide  the  fused  target 
track  and  track  characterizations  necessary  to  support  CID  and  to  resolve  differences  in 
CID  between  TAMD  platforms. 

7.  JDN  and  JCTN  Integration  Tactical  Data  System  and  Links 

Both  JDN  and  JCTN  will  provide  an  interface  with  the  host  tactical  data 
system  (to  include  combat  direction  system  and  weapon/fire  control  systems  as 
appropriate).  The  interface  between  the  JDN  and  host  combat  system  will 
provide  for  the  exchange  of  system  tracks,  track  attributes,  and  command  and 
control  information  (such  as  ID,  force  engagement  orders,  etc.)  necessary  to 
maintain  a  SIAP  and  to  coordinate  command  and  control  and  weapon  systems 
between  multiple  platforms.  The  interface  between  the  JCTN  and  the  host 
combat  system  will  provide  for  the  exchange  of  system  tracks,  track  attributes, 
sensor  derived  measurement  data,  and  command  and  control  information  to 
support  SIAP  and  integrated  fire  control  between  participating  JCTN  platforms. 

Additionally,  integration  of  JCTN  and  JDN  will  be  performed  to  support 
seamless  TAMD  operations  and  SIAP  across  networks.  JDN  and  JCTN 
integration  will  provide  for  the  integration  of  tracks,  track  attributes,  and 
command  and  control  information  between  the  JDN  and  the  JCTN.  Integration 
functions  will  include,  but  are  not  limited  to  automatic  selection  and  filtering  of 
data  to  be  transferred  from  the  JCTN  to  the  JDN,  gridlock  and  correlation  of 
JCTN  &  JDN  tracks,  management  of  track  and  track  attributes  to  ensure  that  a 
consistent  track  picture  is  maintained  between  the  JDN  and  JCTN  (i.e. 
single/common  system  track  number  on  each  track),  and  translation  between 
network  coordinate  reference  frames. 
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8.  Sensor  &  Engagement  Coordination 

Sensor  coordination  will  include  pre-emptive  and  reactive  planning  and 
management,  and  real-time  dynamic  coordination  of  TAMD  sensors  in  support  of 
collaborative:  1)  surveillance  and  tracking:  2)  target  characterization,  identification  and 
discrimination,  and;  3)  real-time  sensor  support  for  cooperative  engagements,  including 
precision  cueing  and  other  coordination  concepts  detailed  in  “Multi-Platform  Weapon 
System  Integration”.  Sensor  coordination  will  include  planning,  management,  and  real¬ 
time  coordination  of  sensor  waveforms  and  coverage  between  multiple  platforms  to 
more  effectively  manage  sensor  resources  and  improve  detection  and  engagement 
performance  against  all  TAMD  threats. 

Engagement  Coordination  will  include  pre-emptive  and  reactive  planning  and 
management,  and  dynamic  coordination  of  TADM  weapon  systems  in  support  of 
collaborative  Joint  battle  force  engagement  coordination  and  support  for  cooperative 
engagement  execution.  Specific  functions  to  be  performed  will  include,  but  not  be 
limited  to: 

■  Providing  weapon  and  sensor  system  capabilities  &  status 

■  Coordinating  sensor  resource  allocation  and  engagement  decisions  (e.g.  J9. 1, 
J12.0,  ABMA-engagement  recommendations,  Joint-TEWA) 

■  Coordinate/share  engagement  status  (e.g.  J10.2) 

■  Coordinate/share  kill  assessment  results 

9.  Weapon/Fire  Control  System  Integration 

Interface  with  fire  control  quality  sensors  and  provide  fire  control  quality  sensor 
measurement  and  composite  track  data  to  Joint  TAMD  weapon  systems  in  support  of 
IFC  engagement  execution  using  locally  derived  and  remotely  provided  data.  Multi¬ 
platform  weapon  system  integration  functionality  will  enable  execution  of  Air-Directed 
SAM  (ADSAM),  Air  Directed  AAM  (ADAAM),  and  Surface  Directed  SAM  (SDSAM). 
Specific  functions  to  be  performed  will  include,  but  not  be  limited  to: 

■  Coordinate  sensors,  weapons  and  communication  systems  to  support  the 
execution  of  IFC  engagements 

■  Provide  tasking  to  fire  control  sensors  to  support  IFC  engagements 

■  Provide  sensor  measurement  data  to  support  weapons  system  guidance 

"  Coordinate  and  execute  hand-over  of  weapon  control  to  like  or  unlike  remote 
systems 
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